mdj33
mdj33
after executed 1. zk init 2. zk server 3. zk prover or zk dummy-prover (another terminal) try to run "zk test i server" at 3rd terminal, it reports error as...
当L2的proof在L1验证失败无法fix时候需要采用回滚机制。 1. 支持pause机制，在relayer监测到L2 deposit和L1不一致时候，尽快设置L2 pause 禁止各种操作，检查无误后恢复 2. 支持设置exodus模式和exodus回滚，只会回滚和L1相关的operation，然后构建逃生舱证明，从L1退出
之前回滚是考虑平行链上设置无效交易，然后从头重新同步平行链达到回滚效果，需要回滚时间长。往往需要回滚时候就是最后几笔交易 优化方案改为记录操作队列，通过设置回滚交易，从最近的操作队列回滚，不需要从头执行区块链
当前平行链节点启动会从已有区块继续执行，不会对历史区块做是否和当前的bin一致的计算结果的校验。 比如一个新版本启动，不会对旧区块做校验，现在要求运维每次更新必须删除旧区块，重新执行比对block hash是否和曾经区块一致来校验。非常不方便，而且容易遗漏或犯错。 期望每次启动增加对历史区块的校验机制。如果校验失败，则panic，提示用户增加fork或其他操作。 大概实现是： 1. 在当前下载层，执行层基础上增加校验层。校验和下载执行同步进行，不影响区块下载和执行，但是在没有校验完成时候暂停共识的发送。 2. 对已经校验了的高度和当前bin的git 版本号绑定保存数据库，方便下次重启从上次校验高度继续校验，而不是从头校验。如果启动发现当前bin的git版本号和数据库的不一致，则从0开始校验。
EROR[01-25|06:43:44] PrefixScan it.Value() module=db.ListHelper error=nil EROR[01-25|06:43:44] PrefixScan it.Value() module=db.ListHelper error=nil EROR[01-25|06:43:44] PrefixScan it.Value() module=db.ListHelper error=nil INFO[01-25|06:43:44] procNewHeight module=ethereum_relayer currentHeight=17 ethRelayer.eventLogIndex.Height=0 uint64(ethRelayer.maturityDegree)=1 ================== WARNING: DATA RACE Read at 0x00c0000d6930 by goroutine...
auth authHash=18304251578373816561719146667419433055631301806215268943112697989385852434346,authKey=16678747381284372741157128409332526143974006721672403765375251027071805395166 0x7b0faf69b8ec82d06ea18fabd583ce08b6d84e400b5e967b4283db87b43c15d7 wait new block 0/10 s, cur height=523,old=522 query hash is 0x7b0faf69b8ec82d06ea18fabd583ce08b6d84e400b5e967b4283db87b43c15d7, return 0x7b0faf69b8ec82d06ea18fabd583ce08b6d84e400b5e967b4283db87b43c15d7 query tx=0x7b0faf69b8ec82d06ea18fabd583ce08b6d84e400b5e967b4283db87b43c15d7 success Error: The operation was canceled.
平行链共识节点即挖矿节点，如果开启挖矿，则需要解锁钱包，这样会增加暴露私钥风险，如果考虑代理挖矿的机制， 共识节点账户和挖矿奖励账户分离，将有很多好处。即便用户丢失了挖矿节点的私钥影响也不大，只要保管好奖励账户私钥即可
1. 平行链交易支持只在某个通道上打包，通道可以是对总通道的取余 2. 不同平行链在主链上使用通道来分割 3. 交易结构增加一个通道的参数，打包区块只打包符合通道的交易
1， 这个多项式的第三项是否应该是(Wc(x)+beta.k2X+gama)? 而不是Wa(x)?  2, 请郭老师更细化一下这一部分的思路，比如为什么随机化要做copy constrain，为什么需要更多随机数？谢谢 
hi, I studied the changePubKey process of zksync, on process is firstly changing pubkey in L1, then L2 also send a changePubkey tx which signed the pubkey_hash with corresponding L2...