[Devcon5] Abstract Reviews
Devcon5에서 정말 다양한 세션들이 4일에 걸쳐 열렸습니다. 이번 포스트에서는 개인적으로 봤던 세션들을 정리하려 합니다. 가능한 많은 세션들을 다루기 위해서 추상적으로 서술하였지만, 중요하거나 기술적으로 재미있는 주제들은 이후 포스트로 개별적으로 깊게 다룰 예정입니다. 또한 워크샵들은 실습 자료가 충분히 제공되어 있기 때문에 관련 링크로 대체합니다.
1. Why Dapp Users Will Hate Cross-Shard Comumnication and What You Can Do About It
Crosslink는 비컨 체인을 통해 cross-shard comunication을 하는것을 의미합니다. 세션에서는 train-and-hotel 문제와 유사한 MakerDAO의 CDP 청산을 예시로 어떻게 해결할 수 있는지 몇가지 아이디어를 제시합니다.
- Consensus Lookahead
샤드 B의 next validator에게 샤드 A에서 발생한 crosslink를 전달하고, 이를 샤드 B에서 같은 시점에 처리 되도록합니다. next validator를 찾는 것이 항상 가능한 이유는 샤드 검증자는 비컨 체인의 검증자이기도 하기 때문입니다. 하지만 이 아이디어는 프로토콜의 변경을 요구합니다. - Synchronizing Shard
crosslink를 비컨 체인을 통하지 않고 갹 사드끼리 처리 한다면 train-and-hotel 문제는 발생하지 않을 것입니다. 하지만 이는 각 샤드들을 tightly-coupled하게 만들 것이고 eth2의 확장성을 다소 훼손할 것입니다.
Related
- https://ethresear.ch/t/cross-shard-communication-developer-experience/1446
- https://ethresear.ch/t/synchronous-cross-shard-transactions-with-consolidated-concurrency-control-and-consensus-or-how-i-rediscovered-chain-fibers/2318
- https://ethresear.ch/t/cross-shard-locking-scheme-1/1269
- https://ethresear.ch/t/fast-cross-shard-transfers-via-optimistic-receipt-roots/5337
2. The Road to Eth 2, Phase 2 & Phase 2 Testnet & Ewasm 2.0: State Execution in Eth 2.0(일부)
Phase 0 비컨 체인의 스펙이 완결되었습니다. 두 세션에서 다루는 EE와 관련된 내용은 다음과 같습니다.
Scout
Scout은 Phase 2 execution prototyping engine 입니다. 특정 YAML파일을 통해 실행 환경에 대한 정보를 파악하여 Phase 2의 state transition function을 실행하여 결과를 반환합니다. 물론 API로 실행할 수 도 있으며, 직접 소스 코드를 import하여 native하게 사용할 수 도 있습니다.
다양한 언어(rust, TS, C++)을 지원하지만 rust버전은 다소 outdated 되었다고 하며, TS버전이 가장 활발히 진행중입니다.
여러 팀들이 eth2 클라이언트를 각자 개발하고 있는 상황에서 execution 부분은 적어도 scout을 이용하여 통합적으로 개발되거나 의사소통 할 것으로 보입니다.
Sheth
Scout이 execution을 담당한다면, Sheth는 EE(execution envirionment)를 제공합니다. eth2 클라이언트는 stateless하기 때문에 검증자들은 state provider (or relayer)에서 EE를 받아야 합니다.
한 머클 트리의 각 leaf들을 모두 전달하지 않는 경우도 있기 때문에 multiproof를 이용하여 머클 검증에 필요한 리소스를 최소화합니다. 이와 관련하여 TurboProof?(gballet, s1na)에서 제작한 multiproof-rs, turbo-token가 merkle branch와 operation을 이용해 머클 트리를 재구성하는 아이디어로 효율적인 검증을 구현중입니다.
Related
3. Eth 2.0 Light Clients: How Light is Light?
eth1의 검증자(마이너)는 라이트 클라이언트를 사용할 수 도 있지만, 여러가지(블록체인 데이터 크기, 풀노드 의존성, 네트워크 지연, PoW 경쟁)를 고려하면 풀노드를 운영하는게 이익입니다. 하지만 eth2의 검증자는 각 체인(샤드 체인, 비컨 체인)의 풀노드일 수 없습니다. 일정한 주기로 다른 샤드로 랜덤하게 재배정되기 때문에 각 샤드 체인의 데이터를 얻기 위해서는 light client를 이용해야합니다.
PoW(eth1)의 PoS(eth2)의 fork choice rule은 다소 다릅니다. PoW에선 orphan 블록 발생 가능성이 (상대적으로) 높지 않으며, slot마다 블록이 없는 경우가 문제되진 않습니다. eth2의 fork choice rule인 LMD GHOST(Least Message Driven GHOST)는 블록의 메시지(block producing, attestation)가 모여있는 정도로 각 포크별로 점수를 냅니다.
(LMD GHOST 및 Casper CBC에 대한 자세한 내용은 다른 포스트에서 다룰 예정입니다.)
LMD GHOST는 eth2의 sync protocol을 기존 eth1 클라이언트와 다르게 만듭니다. 과거 블록 해더를 하나씩 검증하지 않고 즉시 현재 현재 해더들로부터 attestation을 확인한다면 싱크할 포크를 쉽게 선택할 수 있습니다.
4. Ethereum 2.0 Trustless Staking Pools
eth2의 검증자들은 32ETH의 고정된 예치금을 지불해야합니다. 기존에 논의되던 1000ETH보단 적은 금액이지만, 32ETH 또한 탈중앙성을 훼손하지 않기 위하여 PoS 풀이 구성될 수 있습니다. 물론 중앙화된 방식으로는 어떤 방식으로도 만들 수 있지만, eth2의 검증자는 slashing이 가능하기 때문에 attributable fault(정직한 유저는 패널티를 받지 않음)가 없는 풀의 참가자들은 자신의 자산을 보호받아야 합니다. 물론 탈중앙화된 방식으로요.
Trustless Staking Pools에서는 BLS signature, Shamir Secret Sharing (with BLS), Proof of Custody, Legendre PRF를 이용하여 검증 풀의 참가자들의 security를 보장하고, attributable fault를 구성하기 위하여 PBFT 합의를 이용합니다.
(Trustless Staking Pool에 대한 자세한 내용은 다른 포스트에서 다룰 예정입니다.)
Related
- https://medium.com/cryptoadvance/bls-signatures-better-than-schnorr-5a7fe30ea716
- https://blog.dash.org/secret-sharing-and-threshold-signatures-with-bls-954d1587b5f
- https://www.binance.vision/security/threshold-signatures-explained
- https://github.com/ethereum/eth2.0-specs/blob/dev/specs/core/1_custody-game.md
- https://en.wikipedia.org/wiki/Legendre_symbol
- https://tendermint.com/docs/introduction/what-is-tendermint.html#consensus-overview
5. The CBC Casper Approach to Sharding
본 세션은 CBC Casper를 샤딩에 적용하는 CBC Shardfing의 아이디어 제안입니다.
모든 cross-shard message는 eth2와 다르게 항상 프로토콜에 의해 부모 체인을 통해 다른 자식 체인으로 비동기적으로 전달됩니다. (eth2에서는 샤드 체인 검증자에 의해 crosslink가 포함될지 결정됩니다.) cross-shard message의 send-receive atomicity를 강제하기 위하여 샤드 체인의 fork choice는 비콘 체인의 fork choice(CBC)를 따릅니다.
CBC 샤딩에서 샤드 체인(자식 체인)과 비콘 체인(부모 체인)의 계층 구조는 2개 이상의 레이어를 형성할 수 있습니다. 사용자들이 많이 이용하는 컨트랙트(e.g., DAI)가 위치한 샤드의 경우 많은 메시지를 받을 것이기에 load balancing을 통해 더 높은 레이어에 위치시킵니다.
모든 cross-shard message가 프로토콜에 의해 강제된다는 점을 두고 Vitalik은 cross-shard message가 많을 수록 루트 샤드의 load가 증가하여 확장성이 최대 40배(가정: cross-shard message이 모든 샤드 체인에서 발생하는 메시지의 5%이며 uniform하게 분포)정도일 것이라 말하지만, Aditya Asgaonkar는 cross-shard message을 처리하는 부하 또한 가정(전체 시스템의 10%정도)해야 한다며, 확장성은 최대 400배일 것이라 주장합니다.
Related
6. Build a constraint system, prover and verifier using OpenZKP Stark (Workshop)
OpenZKP Stark는 StarkDEX 테스트넷 데모에 사용된 zkp 검증 프로토콜을 별도로 분리한 구현체입니다. 본 workshop에서는 Fibonacci를 예제로 사용했습니다. 검증 단계는 1) TraceTable을 구상하고, 2) 각 row의 Constraints를 정의하고, 3) Provable과 Verifiable을 구현하고, 4) 이를 이용해 prove, verify 합니다.
Materials
- https://docs.google.com/presentation/d/1SSEX-Y_PynyrAGXVeICL-L-fe7KsZ2c3aroneWI-qjA/edit#slide=id.g49ce1038fe_4_8
- https://docs.rs/zkp-stark/0.1.2/zkp_stark/
- https://github.com/0xProject/OpenZKP/tree/master/crypto/stark/examples
Related
7. Defense Against (the Dark Arts) — Contract Runtime Mutability
CREATE2를 이용해 컨트랙트를 생성할 때의 이점은 address, salt, init_code를 통해 생성된 컨트랙트의 주소를 특정할 수 있는 점입니다. 이는 state channel의 counterfactual contract 개념을 구현하는데 아주 유용합니다. 특히 CREATE와 다른 점은 CREATE2를 통해 기생성된 컨트랙트를 selfdestruct한 이후 다시 생성할 경우에도 동일한 주소를 가진다는 점입니다. 해당 세션에서는 CREATE2를 통한 contract redeployment 기법(Metamorphic) 및 해당 방식으로 배포된 컨트랙트가 가질 수 있는 런타임 취약점을 다룹니다.
(Metamorphic에 대한 자세한 내용은 다른 포스트에서 다룰 예정입니다.)
