Research meeting - april 3, 2023

Research
1

agenda

gas table proposal review

  • Iddo, Noam, Wojteck please review Gas cost for precompiles ahead of meeting
  • expected outcome
    • a finalized approach to calculate gas table

post param finalization (for real!)

  • determine whether it’s more cost-effective to rent gpu or run a gpu farm than storing data
  • expected outcome
    • decide initialization time and unit size

malfeasance proof for NIPoST verification

  • if one of the k2 indices fails to verify, we should generate a malfeasance proof of (ATX, bad_index)
  • expected outcome
    • spec

smapp key derivation

  • timeline for solana-keygen adoption
  • expected outcome
    • do or dont for key derivation on smapp at genesis, or do we even need to tie the timeline to genesis

hardware wallet path forward

  • Lane please find out byte limit for the hardware wallet we are supporting (ledger? trezor?)
  • expected outcome
    • game plan for hardware wallet and the sdk

path forward to vm design

  • based on the research discussion in gdansk, we need to figure out the next step of research for vm
  • Wojtek had recorded his view from the discussion
  • expected outcome
    • a process to achieve consensus for vm design
1 Like
2

meeting summary

post param finalization

  • would like to see results from different sets of parameters and compare
    • probability of success in the 1st pass
    • verification time
  • NJ brought up another criteria that high-tier machine from honest miners should not be penalized. this is originally not a consideration of the jupyter notebook
  • 2 sets of params
    • from notebook: K1=279, K2: 300, K3: 65 (with 21 nonces?)
    • from Iddo: K1 slightly less than K2, K2 = 200, K3 is frozen to K2 (with 12-15 nonces)
  • AI:
    • Bartosz get actual number (probability of 1-pass success and verification time) with these 2 sets of param
    • NJ and Iddo based on the numbers decide which one fits the security we want (storage vs recalculating, verification time)

malfeasance proof for NIPoST verification

  • if one of the k2 indices fails to verify, we should generate a malfeasance proof of (ATX, bad_index)
  • this is a different kind of malfeasance proof than previous
  • if miner signs an ATX that contains an index that doesn’t meet the difficulty threshold, this miner is considered malicious
  • the malfeasance proof is verified by verifying the bad index indeed didn’t meet the difficulty threshold
  • AI:
    • kimmy to file an issue

smapp key derivation

  • Dmitry provided Kirill with necessary lib/binding for solana-keygen
  • Kirill can integrate it fairly quickly, before genesis
  • Lane want to use that for smcli
  • AI:
    • Kirill integrate into smapp
    • Lane integrate into smcli

path forward to vm design

  • protocol design:
    • our L1 and L2 architecture is different from conventional notion of Ethereum L1/L2 separation
    • in our protocol, L1 and L2 are in the same network
      • L1 transactions are submitted to L1 miners, executed by L1 miners, and stored in mesh.
      • L2 transactions are submitted to L1 miners, executed by L2 validators, and stored in mesh.
    • basically offloading vm execution to a separate set of machines
    • 2 options for proving system btw L1 and L2
      • optimistic rollup
      • zk rollup (require 3rd role provers to generate zk proof)
  • revisited the requirement to be etheruem tooling compatible
    • find out to what degree our L1 is evm tooling compatible
    • if so, we could plug in an evm at L2 for prototyping. if not, we may have to push out evm tooling compatibility to L3
    • evm tooling compatibility is about ease of adoption at the beginning and buy us time to develop tooling. for example, at the beginning we may use native app (smapp) to handle txs with nonce gap, while using existing ethereum tools to handle contracts that requires sequential nonces. the expectation is that overtime our own tooling will grow/mature.
  • zk proofs are expensive to generate (from NJ, ~128CPU cores and ~512GB ram), zk talents are expensive to acquire
  • AI:
    • NJ find somebody to work with Lane on finding out how evm-tooling compatible is spacemesh network
    • kimmy work with Iddo and Tal to provide documentation for detailed protocol design
1 Like