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