배경
공유 시퀀서 에 대한 내 게시물을 읽어보세요.
트랜잭션의 원자적 포함을 허용하는 공유 시퀀서가 많이 만들어졌습니다. 그러나 이를 위해서는 모든 구성 요소 롤업에 대한 프로토콜 변경이 필요합니다. 이러한 프로토콜 변경 사항은 지정되지 않았으며 아이디어는 털이 많고 이상합니다.
내 생각엔 공유 시퀀서 사람들이 신비롭게 보이도록 너무 복잡하게 만든 것 같습니다. 그래서 나는 앉아서 기본적인 크로스 롤업 묶음 구성표를 디자인하기로 결정했습니다.
다행스럽게도 우리는 임의의 번들링 방식에 대한 선행 기술을 갖고 있으므로 피해야 할 사항과 일반적으로 이를 구성하는 방법을 알고 있습니다. 각 롤업의 필터링 기능을 수정하는 것은 쉽다는 것이 밝혀졌습니다.
목표
여러 EOA의 여러 트랜잭션을 허용해야 합니다.
번들을 분리하는 것은 불가능해야 합니다(동일한 순서에 다른 모든 트랜잭션을 포함하지 않고 구성 요소 트랜잭션을 포함).
공유 TX 형식은 필요하지 않습니다.
서명하는 것이 저렴해야 합니다(최악의 경우 2차 한숨 문제를 참조하여 거래 수에서
O(n)).
구성 요소 롤업 TX 형식 수정
모든 경우에 서명을 생략합니다.
tx에 체인 ID 또는 기타 도메인 바인딩을 포함합니다.
다른 수정 없음
동고
각 구성 요소 롤업에 대해 EOA 주소를 해당 주소의 트랜잭션 목록에 매핑하는 데이터 구조를 갖습니다. 트랜잭션은 직렬화되어야 하며 불투명 바이트로 표시되어야 합니다. 서명자는 내용을 이해할 필요가 없습니다.
struct Bundle {arbitrum: Map<Address, Vec<OpaqueBytes>>,optimism: Map<Address, Vec<OpaqueBytes>>,}서명
롤업과 보낸 사람에 대한 구분 기호를 삽입하여 모든 트랜잭션을 반복합니다. 이렇게 하면 txn이 특정 롤업 및 특정 EOA에 바인딩되어 잘못 해석될 수 없습니다. 또한 관찰자가 tx 구조를 이해할 필요 없이 롤업 및 EOA 정보가 모든 관찰자에게 노출되도록 보장합니다.
이 방식으로 서명하면 모든 서명이 모든 트랜잭션에 커밋되도록 보장됩니다. 이렇게 하면 번들이 수정 불가능해집니다. 확장하거나 번들 해제할 수 없습니다.
fn signing_hash(&self) -> [u8;32] {let mut hasher = Keccak::new();hasher.update(b"arb");for (from, txns) in self.arbitrum.iter() {hasher.update(&from);txns.for_each(|tx| hasher.update(tx.hash()));}hasher.update(b"opt");for (from, txns) in self.optimism.iter() {hasher.update(&from);txns.for_each(|tx| hasher.update(tx.hash()));}hasher.finalize()}fn sign(&self, key: &SigningKey) -> Signature {key.sign_raw(self.signing_hash())}원하는 경우 추가 도메인 바인딩도 사용하세요.
확인 중
전송 내용을 이해하지 못한 채 검증이 이루어질 수 있습니다.
우리는 다음을 통해 확인합니다:
번들에 대한 서명 해시 계산
번들에 대해 선언된 각 EOA에 서명 해시에 대한 서명이 있는지 확인
struct SignedBundle {bundle: Bundle,signatures: Vec<Signature>,}fn verify(bundle: &SignedBundle) -> Result<()> {let signing_hash = bundle.bundle.signing_hash();// Collect the signers whose signatures are includedlet addresses = bundle.signatures.map(|sig| sig.recover_raw(signing_hash)).collect::<Result<HashSet<_>>>();// collect the stated EOA senderslet eoas = bundle.arb.keys().chain(bundle.opt.keys()).collect::<HashSet<_>>>();// Check that those sets are equalif eoas != addresses {return Err("missing sig or extra sig or whatever")}Ok(())}이러한 방식으로 우리는 모든 서명이 모든 거래에 적용되고(거래가 추가, 제거 또는 대체되는 경우 유효하지 않음) 서명으로 인해 드러나는 거래가 없도록 보장합니다. 추가 수표를 만드는 것도 그리 비싸지 않습니다.
직렬화 중
누가 신경쓰는지는 사소한 일입니다. 그냥 그 일을 하세요.
필터링
구성 요소 롤업은 확인에 실패한 번들을 필터링해야 합니다. 필터링에는 거래 내용에 대한 지식이 필요하지 않고 서명만 확인하면 됩니다.
즉, 서명이 올바르지 않거나 불충분한 번들은 호스트 기록에 포함되지만 롤업 기록에서는 필터링됩니다. 롤업 체인에는 아무런 영향을 미치지 않습니다. 오늘날 메인넷의 롤업에 있는 시퀀서 출력의 유효하지 않은 트랜잭션에 대해서도 동일한 작업이 수행됩니다.
결론
이는 다자간 번들에 대한 원자적 포함을 달성합니다. 여러 EOA에 트랜잭션이 포함될 수 있습니다. 모든 서명이 모든 txns에 커밋되므로 번들은 분할될 수 없습니다. 서명은 트랜잭션 수에서 O(n) 입니다. 검증은 O(n + s) 입니다. 여기서 s 는 서명자의 수입니다. 원하는 경우 집계 가능한 서명 체계를 사용하여 트레이드오프를 약간 조정할 수 있습니다.
팔. 목표 달성.
그렇다면 이것이 우리에게 무엇을 얻지 못합니까? 내 과거 블로그 게시물과 짜증나는 트윗 스레드를 읽은 기민한 독자라면 아마도 이런 방식으로 번들링하면 원자 실행을 얻을 수 없다는 것을 깨달을 것입니다. 네. 따라서 실행 부분을 처리하기 위한 추가 메커니즘/프로토콜 변경 없이는 상호 운용성 체계를 구성하는 데 실제로 이것을 사용할 수 없습니다. MEV 추출 블록 빌더는 블록 상단에 위치하여 실행됩니다. 하지만 최종 사용자인 당신은 정보를 추출하지 않습니다. 당신은 추출됩니다.
그렇습니다. 번들링 체계를 구축하는 것은 쉽지 않습니다. 하지만 문제를 거의 쓸모가 없을 정도로 좁혔기 때문입니다.
요약하자면, 원자 포함은 정말 어이없고 쉽고 MEV 추출을 제외하고는 그다지 좋지 않습니다. 큰 일을 그만 두십시오.
