shouki 🧬🐙🪼

短い文章ですが、Ethereumへの思いを書きました Ethereumの物語は始まったばかりです。 同じ時間軸で生きる皆さん、私や @NyxFoundation と一緒に歴史を作りましょう！ note.com/nyxfoundation/…

The new programming language that I'm creating called Concrete has what I consider multiple improvements over Rust without becoming a daemonic academic Haskell like brother. I'm bringing the best of Ada and SPARK dialect and Lean4 into practical system programming. Thanks to it's design it can't have supply chain attacks either. I will be talking and showing code in videos in the upcoming months.

Slides available! docs.google.com/presentation/d…

@shogochiai はい、クリプト・インベントリは進んでるようですね

@adust09 逆にこんな急だと既存金融の改修特需が生まれそうな

ですです。移行に間に合わなかった場合のプランBも議論されました。例えば使い捨てのECDSAでその場をしのぐ案なんかも出てます ethresear.ch/t/native-ephem…

@missbitcoin_mai 胸熱ですね～ ジャスティンはビットコインを救いたいんでしょうね

EFとBlockstreamのメンバーらが参画してるのか！この大きな脅威に一丸となって立ち向かってるの胸熱❤️‍🔥

@nook_ethereum そうですね、要件が定かではありませんがこのzkVMを直接統合するのは不可能です

@adust09 ビットコインで採用されるためにはOP_CATの導入がまず必要だよね？

量子コンピュータの脅威が話題なので追記 lean VMはEthereumのPQC移行に必要なzkVMです。 しかしEthereumだけでなく、Bitcoinや他のブロックチェーンに採用されることを目指しています。 すでにEFの専門チームに加え、Blockstreamのメンバーらが参画してます。(私も去年まで開発に携わってました)

ラフな三層レイヤーの構想は去年の時点でチェックしてた @tcoratger/ryS1ElrWbx#Consensus-The-Decoupled-Protocol" target="_blank" rel="nofollow noopener">hackmd.io/@tcoratger/ryS…

ブロック生成とファイナリティのパイプラインを完全に分離する提案 これにより、ブロック生成の高速化とファイナリティの高速化を同時に追求できる。 ethresear.ch/t/unblocking-f…

Ethereumに特化したP2P実装「ethp2p」がついに公開されました。 今までのlibp2p/GossipSubはethp2pに置き換わります QUICを前提にした垂直統合はもちろん、バリデータのプライバシーを保護する機能も追加されます。 github.com/ethp2p/ethp2p

@pirapira ですね、いい時代です！

仕事が早すぎますw

@shogochiai しかも最前線なんすよねぇ

最ベテランがずっと仕事してて尊い

President Trump's Cyber Strategy for America whitehouse.gov/wp-content/upl…

@nakajo はい、考えることたくさんあるのに年内は無理がありました。8141を統合しても耐量子署名はまだ先なので焦る必要もないんですよね

あと、追加の署名検証アルゴリズムも結局precompileで提供するので、都度アップグレードが必要になるもんね。EIP-8141入れただけでは解決にならないから、過度な複雑性持ち込むだけに見えるね。僕も慎重派の意見に賛成だな。

ただトランザクション作ればいいから、考えてトランザクション作らないといけない　になるからUXとしてはかなりのインパクトだよね。wallet側がどこまで対応するかがかなり大事な気がする。一方でセキュリティの強度をユーザにある意味ゆだねることになるのでそこもしっかり考えないと危なそう。

leanVm for Bitcoin💪

We've implemented EIP-8025 (Optional Execution Proofs) in @ethrex_client. EIP-8025 lets consensus clients request and verify zkEVM proofs of block execution. Validators check a proof instead of re-executing the block, a step toward proof-of-proof-of-stake. @ethrex_client already had witness generation and zkVM guest programs for L2, plus distributed proving. We brought all of it to L1. We're passing the new zkEVM execution spec tests from ethereum/execution-spec-tests. Each fixture ships a pre-built witness with the block, the same setup that a beacon node sends under EIP-8025. The demo shows the proof lifecycle: - Block produced and submitted through the standard Engine API - Proof requested, coordinator dispatches to prover via TCP - Prover executes the block statelessly, submits the proof - Proof delivered via HTTP callback - Verification: SYNCING (no proof yet) → VALID (proof verified) Three terminals running locally: ethrex node with proof engine, L1 prover worker, and our REPL acting as a mock beacon node. The demo uses no-op proofs (re-execution only). ZK proof integration is next. Try it yourself. Instructions in the PR below.

EIP-8141がHegotáのスコープから外れました。 Vitalikが宣言した年内のNative AA達成は頓挫か ↓昨日のコール #t=251" target="_blank" rel="nofollow noopener">forkcast.org/calls/acde/233…

At the Beast Event of @EthCC about the future of zkVMs. A lot of discussions about security and formal verification, with high optimism that AI will enable full formal verification,combined with the other techniques like fuzzing.