이 글은 Nethermind 에서의 박사 과정 인턴십의 결과로 제작되었습니다. Nethermind 연구팀, 특히 여러 초안에 대해 유익한 피드백을 제공해 주신 Conor McMenamin 과 Lin Oshitani 에게 진심으로 감사드립니다.
I. 국가 잠금: 소개.
제안자가 상태 잠금을 발급하면 사용자의 트랜잭션이 사용자가 지정한 정확한 값의 하나 이상의 저장 슬롯에 접근할 수 있음을 약속합니다. 일반적으로 이 값은 이전 블록의 끝에서 슬롯이 보유했던 값입니다. 제안자는 사용자 트랜잭션이 약속된 저장 슬롯 값을 볼 수 있도록 트랜잭션 순서를 조정합니다. 직관적으로 상태 잠금은 블록 상단 트랜잭션과 비교할 수 있습니다. 첫 번째 트랜잭션은 블록의 다른 트랜잭션이 아직 변경하지 않은 상태를 봅니다. 상태 잠금은 사용자가 자신의 트랜잭션이 이전 블록의 끝에서 특정 저장 슬롯이 보유했던 값을 볼 수 있도록 요청하여 변경되지 않은 상태에 대한 첫 번째 권한 접근을 효과적으로 보호함으로써 유사한 권한을 부여합니다. 그러나 ToB 트랜잭션과 달리 상태 잠금은 여러 트랜잭션이 동일 블록 내에서 상태의 분리된 부분에 대한 첫 번째 권한 접근을 가질 수 있도록 합니다.
II. 상태 잠금의 예상 논리적 진행.
1단계) 사용자는 제안자에게 상태 스냅샷 S를 지정하여 상태 잠금 요청을 보냅니다.
- S는 저장 위치 L1…LN과 해당 값 V1…VN의 집합으로 지정됩니다.
- 요청에는 preTip과 postPayment가 모두 지정됩니다.
2단계) 제안자는 요청에 서명하고 사용자에게 반환함으로써 향후 사용자의 거래가 S에 대해 실행될 것을 약속합니다.
- 이제 제안자는 최소한 사전 팁을 받게 됩니다.
3단계) 사용자는 S가 잠겨 있다는 확인을 받습니다.
4단계) 사용자는 마감일(만료) 전 어느 시점에 후속 거래 T를 보냅니다.
5단계) 제안자는 T를 받고 T가 S에 가장 먼저 접촉하도록 거래 목록을 정렬합니다.
- 블록을 게시하기 전에 제안자는 사용자의 거래를 시뮬레이션하여 S에만 영향을 미치는지 확인합니다. 거래가 S 외부의 저장 위치에 쓰기를 통해 "범위를 벗어난" 경우, 제안자는 사용자에게 증명과 NullificationContract(부록 A 참조)를 제출하고 T를 포함하지 못했다는 이유로 더 이상 슬래싱을 받지 않습니다.
6단계) 제안자는 S에 대해 T를 실행한 대가로 postPayment를 받습니다.
- T가 반환되더라도 postPayment를 계속 받습니다. 성공적인 실행은 약속의 일부가 아닙니다.
III. 시각화.
IV. 설명.
1. 이 제안은 현재 L1 블록 제안자가 상태 잠금 요청/허가의 유일한 처리자라고 추론적으로 가정하지만, 제안자가 게이트웨이나 릴레이와 같은 정교한 제3자에게 권한을 위임할 수 있도록 허용합니다.
2. 제안자가 동일한 블록에 대해 여러 상태 잠금을 부여할 수 있으므로, 후속 거래가 예기치 않게 "범위를 벗어나" 실수로 중복될 위험이 있습니다. 부록 A에서는 실수로 중복되는 문제와 몇 가지 완화 전략에 대해 설명합니다.
3. 상태 잠금을 시행하려면 잘못된 행동(예: 제안자가 후속 거래를 받았지만 포함하지 못함)에 대한 삭감이 필요할 것으로 예상됩니다.
4. 상태 잠금에는 실행 후 보장이 포함되지 않습니다.
5. 제안자는 preTip(후속 조치가 없을 경우) 또는 postPayment 중 하나만 수집하며, 둘 다 수집하지 않습니다. 예를 들어, preTip과 postPayment에 동일한 nonce를 사용하여 서명함으로써 상호 배제를 달성할 수 있습니다.
6. 사용자는 후속 거래를 보낼 필요가 없습니다.
V. 사용 사례.
1. 핵심 사용 사례: 블록 상단 접근의 민주화.
상태 잠금의 핵심 사용 사례는 여러 사용자가 동일 블록 내에서 손상되지 않은 상태에 대한 접근을 보장받을 수 있도록 하는 것입니다. 현재 손상되지 않은 상태에 대한 접근은 블록 상단(ToB) 포함을 위한 입찰을 의미합니다. ToB 트랜잭션은 가장 먼저 참여하기 때문에 전체 상태 트라이에 대해 사실상 상태 잠금을 누리게 됩니다. 이러한 승자 독식 방식은 여러 가지 이유로 최적이 아니며, 그중 하나는 이미 언급했듯이 블록당 하나의 트랜잭션만 손상되지 않은 상태에 대한 접근을 보장받는다는 것입니다.
또 다른 문제는 ToB 포함에 당첨되는 사람은 실제로 필요한 것보다 더 많은 비용을 지불할 가능성이 높다는 것입니다. 거래는 특정 풀에만 접근하면 되지만, 사용자는 상태 루트를 효과적으로 잠그기 위해 비용을 지불합니다. 그리고 이러한 과도한 지불에도 불구하고, ToB 포함에 대한 삭감 가능한 보장은 여전히 받지 못합니다. 낙찰자는 다른 모든 입찰자와 마찬가지로 비용을 지불하고 거래가 어떻게 될지 기다립니다.
상태 잠금은 이러한 역학을 근본적으로 변경합니다. 사용자는 ToB 포함 외에도 더 많은 옵션을 가지고 있으며, 원하는 수의 사용자가 먼저 액세스하는 권한을 가질 수 있고, 각 사용자는 관심 있는 상태 부분에만 입찰할 수 있으며, 사용자는 해당 상태 부분이 잠겼다는 삭감 가능한 약속을 받습니다.
2. 핵심 사용 사례에서 비롯된 두 가지 구체적인 예.
상태 잠금은 손상되지 않은 상태에 대한 접근을 보호하는 기능을 하므로, 그 사용 사례는 사용자가 블록 상단에 거래를 기록하려는 이유와 크게 겹칩니다. 이러한 이유나 사용 사례는 많지만, 특히 두 가지를 주목할 만합니다.
2.1 새로운 중재 전략.
블록 상단에서 거래를 확보하려는 주된 이유 중 하나는 차익거래 기회를 확보하기 위한 것입니다. 상태 잠금의 핵심 사용 사례는 이러한 기회를 더 널리 제공하는 것이지만, 상태 잠금은 새로운 거래 전략도 가능하게 합니다. 그 이유 중 하나는 후속 거래가 사용자에게 최대한의 선택권을 제공하기 때문입니다. 일반적인 CEX-DEX 차익거래의 경우, 사용자는 DEX 가격을 잠금하고 만기 직전까지 기다렸다가 후속 거래를 전송하여 가격 편차에서 최대 가치를 추출할 수 있습니다. 또는 예상치 못한 가격 수렴이 발생할 경우, 후속 거래를 보류함으로써 간단히 옵트아웃할 수 있습니다(단, 사전 팁은 지불해야 함). 이를 통해 손실을 피할 수 있습니다.
2.2 저주파 사용자를 위한 중요한 거래 확보.
상태 잠금은 트레이딩 봇을 설계하는 전문 트레이더와 같은 고급 사용자에게 주로 유용할 수 있지만, 특히 중요하다고 생각되는 거래를 전송하는 일반적인 저빈도 사용자에게도 고유한 사용 사례를 제공합니다. DEX에서 (자신에게) 큰 규모의 거래를 하거나 NFT 채굴에 대한 우선 접근 권한을 원하는 사용자에게 상태 잠금은 거래가 실패하거나 선행매매에 이용당하지 않을 것이라는 귀중한 보장을 제공할 수 있습니다.
3. 사전 확인 사용 사례.
상태 잠금 부여는 후속 트랜잭션에 대한 포함 사전 확인으로 볼 수 있습니다. 일반적으로 사전 확인 의 주요 사용 사례는 사용자 경험 향상이며, 특히 기반 롤업 의 맥락에서 그렇습니다. 사전 확인의 한 유형으로 간주되는 상태 잠금은 이러한 사용 사례에 적합합니다. 상태 잠금은 사용자에게 스냅샷에 지정된 조건에서 트랜잭션이 실행될 것이라는 확신을 제공합니다. 하지만 다른 유형의 사전 확인에 비해 장점이 있는 사용 사례도 있습니다.
3.1. 포함 사전 확인보다 더 엄격한 보장을 제공하는 사전 확인.
포함 사전 확인을 통해 사용자는 자신의 거래가 블록에 포함될 것이라는 사실만 알 수 있습니다. 상태 잠금을 통해 사용자는 자신의 거래가 블록에 포함될 것이라는 사실과 그에 따른 정확한 상태를 알 수 있습니다.
3.2. 상태 잠금은 실행 사전 확인보다 제안자/사전 협의자에게 위험이 적습니다.
가장 엄격한 형태의 실행 사전 확인은 특정 실행 후 상태 루트에 대한 확약을 포함합니다. 덜 엄격한 변형은 상태 차이 또는 사용자 의도에 대한 확약이 약합니다. 사전 확인은 실행 후 결과에 대한 책임이 있으므로, 불완전한 모델링/시뮬레이션 예측(예: 잘못된 웜/콜드 가정, 오라클 업데이트 누락, 코드 경로 누락)으로 인해 발생하는 사전 위험을 감수해야 합니다. 특히 사전 확인에 독점적인 블록 빌드 권한이 없는 경우 더욱 그렇습니다. 이와 대조적으로, 상태 잠금은 실행 전 조건에만 확약하여 모든 사전 위험을 경계 범위를 벗어난 위험으로 효과적으로 축소함으로써 이러한 위험을 방지합니다.
언뜻 보기에 제안자 위험 감소가 사용자 위험 증가로 보일 수 있습니다. 하지만 그 상충관계는 훨씬 더 미묘합니다. 제안자는 사전 상태 조건을 약속하고 범위를 벗어난 스크리닝을 통해 이를 강제하는 반면, 사용자는 스냅샷에 명시된 값에 대해 후속 조치를 시뮬레이션합니다. 충분히 정교한 도구를 사용하면 사용자는 제안자/사전 협의자만큼 정확하게 스냅샷을 기반으로 실행 결과를 시뮬레이션할 수 있습니다. 그러나 사전 협의자와 달리 사용자는 시뮬레이션되지 않은 결과에 대해 슬래싱 페널티를 받지 않고 거래 위험과 가스 요금만 부과됩니다. 따라서 상태 잠금은 사후 상태 결과에서 사전 상태 조건으로 책임을 이전함으로써 사용자 위험을 크게 증가시키지 않고 제안자 위험을 줄일 수 있습니다.
3.3. 사용자에게 강력한 선행 보호를 제공하는 사전 확인.
이전 블록의 마지막에 유지되었던 값으로 상태를 잠그면, 사용자는 자신의 트랜잭션이 현재 블록에서 잠긴 상태에 가장 먼저 접근하게 됩니다. 이렇게 하면 다른 트랜잭션이 상태 잠금을 위반하지 않고 후속 트랜잭션을 선점할 수 없으므로, 선행 실행이 사실상 불가능해집니다.
4. 거래의 가스 효율성을 높입니다.
직관적으로, 실행 전 상태를 정확하게 고정하면 트랜잭션 동작을 더 예측하기 쉬워집니다. 결과적으로 트랜잭션은 최적화될 가능성이 더 높아집니다. 이러한 원리를 보여주는 구체적인 사례 중 하나는 EIP-2930 액세스 목록 트랜잭션에 대한 연구 에서 찾아볼 수 있습니다.
EIP-2930 트랜잭션에는 실행 시작 시 "워밍업"되는 주소 및 저장 키 액세스 목록이 포함되어 있어 액세스 비용이 EIP-2929 에 명시된 웜 액세스 비용 으로 부과됩니다. 이 연구의 저자들에 따르면, 트랜잭션 액세스 목록(TAL)의 가스 절감 잠재력은 주로 블록 내 상태와 관련된 불확실성으로 인해 저해됩니다.
"저희 분석 결과, 이상적인 TAL을 포함하면 이익을 얻을 수 있는 모든 거래의 약 71%에서 이상적인 TAL을 마지막 블록의 상태에서 정확하게 계산할 수 없는 것으로 나타났습니다. 대신, 거래가 실행되는 블록 내 상태에 대한 정보가 필요한데, 이 정보는 사전에 알 수 없기 때문에 이러한 경우 TAL을 제대로 계산하는 것은 거의 불가능합니다." (2쪽)
상태 잠금은 정확한 실행 전 상태를 고정함으로써 트랜잭션이 액세스할 모든 저장 키만 포함하는 이상적인 TAL을 계산할 수 있도록 합니다. TAL은 수신자 주소와 같은 기본 웜 주소를 불필요하게 포함하는 등 다른 오류로 인해 불완전할 수 있지만, 가스 사용량을 최대한 최적화하는 완벽한 TAL을 위해서는 정확한 실행 전 상태를 알아야 합니다.
5. 추가 이점: 메모리 풀 경합 감소, 복귀율 감소.
MEV-Boost는 입찰 경쟁, 스팸으로 가득 찬 메모리 풀, 실패한 거래로 막힌 블록 등 우선 가스 경매 와 관련된 많은 부정적 외부 효과를 크게 줄 였지만, 상태 잠금은 메모리 풀 경합을 줄이고 복귀율을 낮춤으로써 블록 생산을 보다 질서 있고 효율적으로 만드는 데 여전히 도움이 될 수 있습니다.
5.1 메모리풀 경합 감소.
Flashbots는 현재 블록 빌더가 mev_simBundle과 같은 API 엔드포인트를 노출할 수 있도록 지원합니다. mev_simBundle을 통해 검색자는 최신 블록 템플릿을 기준으로 번들을 시뮬레이션할 수 있습니다. 새로운 proposer_getLockedStates 엔드포인트를 노출함으로써 제안자는 잠금 상태 목록을 실시간으로 공유할 수 있으며, 이를 통해 합리적인 사용자는 자체 검열을 통해 공개 메모리 풀에서 발생하는 경합을 줄일 수 있습니다. 그러나 이러한 설계 방식은 미공개 거래와 관련된 정보(예: 잠재적 차익거래 대상)를 노출해야 하므로 개인정보 보호 문제가 발생할 수 있습니다.
5.2 복귀율 낮추기.
지갑, dApp 및 정교한 사용자는 정확한 실행 전 상태를 알면 더 높은 정확도로 거래를 시뮬레이션할 수 있으며, 가스 한도 부족, 오래된 예비 값, 외부 호출 실패 등으로 인한 거래 취소를 방지하는 데 도움이 됩니다.
VI. 주요 용어.
우발적 중복: 우발적 중복은 트랜잭션이 상태 잠금 부여로 예약된 상태의 일부에 무단으로 액세스할 때 발생합니다.
- 자세한 내용은 부록 A를 참조하세요.
도메인 : EVM의 지속적 상태에서 주소 지정이 가능한 저장 위치로, {A, K} 집합으로 지정됩니다. 여기서 A는 계약 주소이고 K는 32바이트 저장 슬롯(키)입니다.
도메인-값 쌍 : 도메인 {A, K}와 값 V의 쌍으로, {{A, K}, V}}로 지정됩니다.
- Uniswap V2에서 WETH/USDC 풀을 사용한 구체적인 설명:
- 블록 높이: 22385280
- 도메인: {0xB4e16d0168e52d35CaCD2c6185b44281Ec28C9Dc, 0x…03}
- 값: {0x663047400000000000000000008d9350c2aac000000000124394c1432cced5400}
- 도메인-값 쌍: {{0xB4e16d0168e52d35CaCD2c6185b44281Ec28C9Dc,0x…03}, 0x66304740000000000000000008d9350c2aac000000000124394c1432cced5400}
만료일 : 후속 거래 포함을 강제하기 위한 마감일.
- 만료일은 제안자가 후속 거래를 수신해야 하는 마감일을 설정하며, 이 기간 내에 후속 거래를 수신하지 않으면 제안자는 해당 거래를 포함하지 않아 삭감됩니다. 후속 거래가 만료일 이후에 도착하면 제안자는 해당 거래를 포함하지 않아 삭감되지 않습니다.
후속 거래 : 국가 잠금 허가에 따라 전송된 거래입니다.
- 사용자가 동일한 블록에 포함할 여러 거래를 보내고 그 중 하나가 상태 잠금을 위한 후속 거래인 경우, 후속 거래는 거래의 nonce와 상태 잠금 요청에 지정된 nonce가 일치하는지 여부에 따라 결정됩니다.
범위를 벗어난 액세스 : 후속 트랜잭션이 상태 잠금 요청에 지정되지 않은 도메인에 쓸 때입니다.
권한 집합 : 스냅샷에서 가져온 후속 트랜잭션에 액세스해야 하는 도메인 집합입니다.
A가 계약 주소이고, K가 저장 슬롯이며, V가 K가 예약된 값인 예:
- 스냅샷: {{{A1, K1}, V1}}, {{A2, K2}, V2}}}
- 권한 집합: {{A1, K1}, {A2, K2}}
직관적으로, 권한의 요소 수는 "얼마나 많은" 상태가 잠기는지 계산하거나 측정하는 데 사용될 수 있습니다.
postPayment : 상태 잠금을 이행하기 위한 우선 수수료입니다.
postPayment 금액은 preTip을 포함하여 계산됩니다. postPayment는 사실상 "전액" 우선 수수료입니다.
postPayment = preTip + 후속 거래 포함에 대한 보상
후속 거래에서는 제안자가 사후 지불금을 징수할 수 있는 권한이 부여됩니다.
preTip : 상태 잠금 요청에 포함되는 제안자에게 지급되는 대체 지불입니다.
preTip은 (a) 사용자가 후속 거래를 보내지 못하는 경우 또는 (b) 후속 거래가 스냅샷 외부의 도메인에 쓰기를 통해 범위를 벗어나는 경우 제안자에게 보상합니다(부록 A 참조).
상태 잠금 요청은 제안자가 사전 팁을 수집할 수 있는 권한을 부여합니다.
preTip과 postPayment는 예를 들어, 동일한 nonce로 각각 서명하는 방식으로 상호 배타적으로 만들어야 합니다.
스냅샷 : 상태 잠금 요청에 의해 지정된 모든 도메인-값 쌍의 집합입니다.
- 개략적으로 나타낸 예:
- 단일 주소, 단일 저장 슬롯: {{A, K}, V}
- 단일 주소, 다중 저장 슬롯: {{{A1, K1}, V1}, {{A1, K2}, V2}}}
- 여러 주소, 주소당 단일 저장 슬롯: {{{A1, K1}, V1}, {{A2, K2}, V2}}}
상태 잠금 : 스냅샷에서 지정한 상태 집합에 대해 트랜잭션이 실행되도록 보장하는 축소 가능한 커밋입니다.
- 참고: 상태 잠금이라는 개념 자체는 잠긴 상태에 대해 트랜잭션을 실행한다는 개념을 포함하지 않습니다. 사용자는 다른 사용자의 거래를 방해하는 등 악의적인 목적으로 상태 잠금을 요청할 수 있습니다. 그럼에도 불구하고, 이 용어의 사용은 제한적입니다. 우리의 의미에 따르면 "상태 잠금"은 잠긴 상태에 대해 트랜잭션을 실행하겠다는 약속을 의미합니다.
상태 잠금 요청 : 상태 잠금을 요청하는 서명된 메시지입니다.
- 상태 잠금 요청은 (i) 스냅샷, (ii) preTip, (iii) postPayment, (iv) 후속 거래의 nonce, (v) 후속 거래가 포함될 블록, 그리고 (vi) 만료일을 지정합니다. 사용자는 EIP-712와 같은 표준을 사용하여 서명합니다.
{
blockNumber:…,
snapShot:[(A1, K), (V1)…],
preTip:…,
postPayment:…,
expiry:…,
nonce:…,
}
상태 잠금 부여 : 상태 잠금을 발급하는 서명된 메시지입니다.
VII. 공정한 교환.
후속 문제.
후속 문제의 핵심은 제안자가 사용자의 상태 잠금 요청을 승인하고 후속 거래를 무시하여 약속을 이행하지 못할 수 있다는 것입니다.후속 문제가 사전 확인에 대한 적시 공정한 교환 문제와 동일하지 않다는 점을 명확히 하는 것이 중요합니다.사전 확인은 사전 협의자가 사용자에게 구속력이 있고 시기적절한 사전 확인을 보내도록 하여 UX를 개선합니다.따라서 사전 확인이 적시에 발행되지 않으면 공정한 교환이 위반됩니다.핵심적인 물류 문제는 지연에 대한 경제적 인센티브를 고려하여 적시에 발행을 보장하는 것입니다.반대로 후속 문제는 적시성을 보장하는 것이 아닙니다.대신 핵심적인 물류 과제는 제안자가 사용자의 후속 거래를 포함하겠다는 약속을 이행하는지 확인하는 것입니다(제때 받았다고 가정할 때).
질문: 제안자가 후속 거래를 무시하고 사후 지불을 포기하는 이유는 무엇입니까?
(A1) 충돌하는 거래에 대해 더 높은 입찰을 받았을 수 있습니다.
(A2) 가능한 한 많은 preTips를 수집하기 위해 무차별적으로 상태 잠금 요청을 허용하고 있을 수 있습니다.
이 전략은 자연스럽게 가장 큰 사후 결제를 제공하는 후속 조치만을 포함합니다.
(A3) 제안자는 단순히 사용자를 검열하고 있을 수도 있습니다.
완화 전략.
(S-1) 팁을 선불과 후불로 나누는 것만으로도 사용자에게 어느 정도 보호가 제공됩니다. (팁을 두 부분으로 나누는 아이디어는 제안자 약정 시스템 내에서 공정한 교환 문제에 대한 루반의 해결책 에서 차용한 것입니다.)
사전 팁(preTip)이 작을수록 사용자의 위험 부담은 줄어듭니다. 하지만 제안자의 위험 부담도 그만큼 커집니다. 사용자가 거액의 사후 결제를 약속하더라도 후속 거래를 보내지 않으면 제안자에게 기회비용이 발생할 수 있습니다. 공정한 거래는 여전히 양방향으로 이루어집니다.
(S-2) 제안자는 도메인당, 즉 {A, S} 쌍당 하나의 상태 잠금만 부여할 수 있습니다. 제안자는 잠긴 도메인에 대해 실행되는 비상태 잠금 트랜잭션(사전 확인 포함)을 포함할 수 있습니다. 단, 해당 트랜잭션은 도메인이 더 이상 잠기지 않은 후, 즉 후속 트랜잭션 이후에 실행되어야 합니다.
시행은 제안자가 도메인당 두 개 이상의 상태 잠금을 발행하는 경우 이를 대폭 줄이는 스마트 계약의 형태를 취할 수 있습니다.
장점: 제안자가 도메인에 대한 추가 잠금을 부여할 수 없으므로 무차별적으로 입찰하거나 더 높은 팁을 제시하는 경쟁 상태 잠금 요청을 수락할 인센티브가 없습니다.
단점: 제안자가 (a) 사용자를 검열하거나 (b) 비국가 잠금 거래에 대해 더 높은 입찰가를 받기 위해 사용자의 후속 거래를 무시할 가능성이 여전히 있습니다.
(S-3) 상태 잠금을 배타적 접근 권한으로 취급합니다. 사용자의 후속 트랜잭션만이 해당 권한 집합 P에 있는 도메인을 수정할 권한이 있습니다. 블록의 다른 트랜잭션은 P에 있는 도메인(주소와 저장 키 {A, K}의 쌍)에 쓸 수 없습니다.
장점: 사용자를 (i) 입찰에서 밀리는 것 및 (ii) 사전 팁을 극대화하기 위한 무차별적인 발행으로부터 보호합니다.
단점 1: 이러한 보호는 제안자가 P에 대해 실행되는 추가 거래를 포함하는 능력을 제한하는 비용이 발생합니다.
단점 2: 독점적인 접근으로 인해 요청 비용이 상당히 높아질 수 있습니다.
단점 3: 제안자는 후속 거래를 무시함으로써 여전히 검열에 참여할 수 있습니다.
이는 일관된 주제입니다. 순수한 검열에 맞서 보호하는 것은 어렵습니다.
(S-4) 거래증명위원회.
또 다른 방법은 후속 거래를 제안자와 증명 위원회 모두에게 보내는 것입니다. 위원회의 각 위원은 후속 거래를 받은 시간을 기록하고 다른 위원들에게 소문을 퍼뜨립니다. 위원회 구성원 중 충분한 비율이 만료일 전에 후속 거래를 관찰했다고 증명하면, 제안자는 후속 거래를 포함하지 않았다는 이유로 해고될 수 있습니다.
(S-5) 신뢰할 수 있는 중개자를 통한 라우팅.
위원회 대신 신뢰할 수 있는 중개자를 사용하는 주요 이점은 네트워크 전체에 증명을 전파할 필요가 없다는 것입니다. 따라서 사용자는 후속 거래를 전송하기 전에 더 많은 시간을 확보할 수 있습니다. 주요 단점은 중앙 집중화와 추가적인 신뢰 요소 도입입니다.
(S-6) 온체인 레지스트리에 기록된 제안자에 대한 평판 점수(평판 "슬래싱")입니다.
가장 간단한 경우, 레지스트리를 사용하여 제안자 성과에 대한 원시 데이터(예: 누락된 후속 거래 건수/백분율)를 기록할 수 있으며, 이는 엄밀히 말해 악의적인 행위를 의미하지는 않습니다. 이러한 한계에도 불구하고, 레지스트리는 최소한 위험 평가의 근거를 제공할 것입니다. 사용자는 오류 여부와 관계없이 후속 거래를 누락할 가능성이 높은 제안자(또는 게이트웨이)를 피하고 싶어할 수 있습니다. 레지스트리는 또한 최소 신뢰성 요건을 부과하는 데 사용될 수 있습니다.
적시.
상태 잠금은 우선 수수료를 사전 팁(preTip)과 사후 지불(postPayment)로 나누고, 사후 지불에는 후속 거래 포함 조건을 적용하여 시기적절하고 공정한 교환을 유도합니다. 다른 조건이 동일하다면 , 사용자가 서명된 상태 잠금 부여를 빨리 받을수록 후속 거래의 잠재적 가치가 커집니다. 따라서 상태 잠금 부여 발급을 지연하면 사용자의 가치 손실 위험이 있습니다. 후속 거래에서 충분한 가치가 손실되면 사용자는 이를 전송하지 않기로 결정할 수 있으며, 제안자는 사후 지불을 잃을 수 있습니다. 반대로, 사용자가 상태 잠금 부여를 빨리 받을수록 잠재적 가치가 더 크기 때문에 후속 거래를 전송할 가능성이 높아집니다. 따라서 상태 잠금 부여를 적시에 발급하면 사용자와 제안자 모두의 가치가 극대화됩니다.
고스트 그랜트.
(a) 사용자가 후속 거래를 전송하지 못하거나 (b) 후속 거래가 범위를 벗어나는 경우(부록 A 참조), 상태 잠금 요청은 제안자가 사전 팁(preTip)을 수집할 수 있도록 승인합니다(단, 사전 팁은 사후 지불(postPayment)로 대체/지불되도록 설계되었습니다). 이는 제안자의 위험을 줄이는 반면, 사용자에게 공정한 교환을 거부하는 새로운 방법을 제시합니다. 상태 잠금 요청은 사전 팁 지불을 승인하므로, 악의적인 제안자는 사용자의 후속 거래를 포함하도록 하는 상태 잠금 승인을 발행하지 않고도 사전 팁을 수집할 수 있습니다. 사용자가 전송되지 않은 "고스트" 승인에 대해 비용을 지불하는 경우 공정한 교환이 위반되므로, 핵심적인 물류적 과제는 제안자가 "고스트" 승인에 대한 사전 팁을 수집하지 않도록 하는 것입니다.
사용자는 먼저 승인을 받지 않고 후속 거래를 전송하여 위험을 감수할 수 있지만, 이는 위험하고 불공평합니다. 최상의 시나리오에서도 사용자는 발급되지 않은 상태 잠금에 대한 사후 지불(postPayment)을 지불하게 되기 때문입니다. 더 합리적인 선택은 후속 거래를 보류하거나 일반 거래를 제출하는 것입니다. 따라서 상태 잠금 승인 없이 후속 거래를 전송하는 것은 기술적으로는 하나의 선택이지만, 공정한 교환을 보장하는 데 도움이 되지 않습니다.
더 나은 방법은 제안자가 사용자와 증명 위원회 또는 신뢰할 수 있는 중개자 모두에게 상태 잠금 보조금을 보내도록 하여 제3자 증명을 활용하는 것입니다. 사용자는 제3자가 서명한 누락된 보조금 증빙서(GrantWitness)를 환불 계약서에 제출하여 공정한 교환이 위반되었음을 증명할 수 있습니다. 이 환불 계약서를 통해 사용자는 프리팁(preTip)을 회수하고 제안자에게 삭감할 수 있습니다. 또 다른 방법은 제안자가 프리팁을 회수하기 위해 상태 잠금 보조금을 적시에 보냈음을 증명하도록 요구하는 것입니다. 이 경우, 보조금과 제3자가 서명하여 적시에 발행되었음을 증명하는 전송된 보조금 증빙서(sendGrantWitness)가 모두 포함되어야 합니다. 상태 잠금 요청은 더 이상 프리팁 회수를 승인하지 않으므로 다른 방식으로 지불해야 합니다. 한 가지 방법은 사용자가 프리팁 지급 계약서에 입금하도록 하는 것입니다. 제안자는 보조금과 전송된 보조금 증빙서를 프리팁 지급 계약서에 제출하여 프리팁을 회수할 수 있습니다.
부록.
다음 부록은 다음과 같은 가정을 계속합니다. (i) 현재 L1 제안자(또는 게이트웨이와 같은 대리자)가 상태 잠금 요청/허가의 유일한 처리자이며, (ii) 상태 잠금 허가는 현재 블록의 L1 상태 트라이에서 주소/저장 슬롯 쌍에 대해 정의된 도메인 집합에 속합니다. 이는 단순성과 명확성을 우선시하면서도 폭을 희생하기 위해 만들어진 범위 가정입니다. 따라서 상태 잠금은 일종의 사전 확인으로 간주될 수 있지만, 많은 세부 사항이 L2 변형으로 직접 전달되지 않을 수 있습니다(예: "우발적 중복"에 대한 정의는 EVM 명령어 의미론에 의존합니다).
부록 A: 우발적 중복 문제
상태 잠금은 여러 트랜잭션이 상태의 겹치지 않는 부분에 대한 우선 접근 권한을 가질 수 있도록 합니다. 그러나 이 새로운 기능은 제안자에게 추가적인 위험을 초래합니다. 사용자가 상태 잠금 요청에 후속 트랜잭션을 포함하지 않기 때문에 제안자는 로밍 트랜잭션을 걸러낼 수 없습니다. 제안자는 상태 잠금을 "맹목적으로" 부여해야 합니다. 후속 트랜잭션 중 하나가 다른 트랜잭션을 위해 예약된 상태의 일부에 예기치 않게 접근하는 경우(즉, 실수로 겹치는 경우), 제안자는 슬래싱 페널티를 받을 수 있습니다.
"경계선 초과" 및 "우발적 중복"에 대한 명확한 설명.
범위를 벗어난 액세스는 트랜잭션의 권한 집합에 포함되지 않은 도메인에 대한 모든 쓰기(SSTORE)로 정의하는 것이 가장 좋습니다. 중복되는 읽기(SLOAD, BALANCE, 외부 CALL 함수 보기)는 상태를 변경하지 않으므로 무해한 중복으로 간주될 수 있습니다. 이러한 방식으로 "범위를 벗어난" 액세스를 정의하면 중복되는 Oracle 조회와 같은 작업은 범위를 벗어난 것으로 간주되지 않습니다.
범위를 벗어난 액세스: 범위를 벗어난 액세스는 상태 잠금 트랜잭션 T가 권한 집합 P에 속하지 않는 도메인 {A, K}에 쓸 때 발생합니다.
우발적 중복: 트랜잭션 T1이 T2보다 먼저 실행되고 T1이 T2의 권한 집합에 있는 일부 도메인 {A, K}에 쓸 때 트랜잭션 T1이 실수로 다른 트랜잭션 T2와 중복됩니다.
실수로 인한 중복을 방지합니다.
일반 트랜잭션은 상태 잠금 트랜잭션과 의도치 않게 겹칠 수 있습니다. 이를 방지하는 가장 간단한 방법은 상태 잠금 트랜잭션의 시퀀싱 우선순위를 정하는 것입니다. 하지만 상태 잠금 간의 의도치 않은 겹침은 쉽게 해결할 수 없습니다. 이 부록의 나머지 부분에서는 이를 완화하기 위한 몇 가지 전략을 논의합니다.
최소화 전략 1: EVM 기반 권한 보호.
우발적인 중복을 완화하는 한 가지 방법은 EVM 내부 권한 가드를 사용하여 범위를 벗어난 쓰기 시도를 하는 경우 해당 작업을 되돌려 후속 작업이 원래 차선에 머물도록 "강제"하는 것입니다. 네이티브 프리컴파일과 같은 방법을 사용하여 EVM에서 직접 권한 집합을 적용할 수 있지만, 현재 메인넷에서는 실행 가능하지 않습니다. 새로운 프리컴파일 주소를 도입하려면 공식적인 EIP, 프로토콜 수준의 하드포크, 조정된 Eth 클라이언트 구현, 감사 및 생태계 도구가 필요합니다. 일반적으로 개발, 테스트 및 소셜 조정에 드는 오버헤드로 인해 EVM 기반 접근 방식은 단기적으로 실행 불가능합니다.
최소화 전략 2: 오프체인 시뮬레이션.
또 다른 옵션은 제안자가 오프체인에서 후속 거래를 시뮬레이션하도록 하는 것입니다. 제안자가 실수로 중복을 감지하면, 범위를 벗어난 증명을 생성하여 사용자에게 전송하여 후속 거래를 수정할 충분한 시간을 확보할 수 있습니다. 제안자는 재시뮬레이션을 위한 시간도 필요합니다. 이러한 상호 작용에 대응하기 위해 만료일은 슬롯 초기에 설정되어야 하며, 두 번째 만료일이 필요합니다. 사용자가 두 번째 만료일 전에 "수정된" 후속 거래를 반환하지 못하면, 범위를 벗어난 증명은 NullificationContract로 전송될 수 있습니다.
오프체인 시뮬레이션의 문제점
네이티브 프리컴파일보다 실현 가능성이 높지만, 이 접근 방식에도 몇 가지 어려움이 있습니다. 첫째, 제안자는 사용자에게 거래 목록을 노출하지 않고도 만족스러운 범위 외 증명을 생성할 수 있어야 합니다. 불필요한 레그와의 스왑과 같이 이것이 가능한 경우도 있지만, 이는 예외적인 경우일 가능성이 높습니다. 둘째, 제한된 시간 범위로 인해 수정된 후속 거래에 대한 공정한 교환을 보장하기 어려울 것입니다. 셋째, 무효화 계약은 범위 외 증명에 대한 제안자와 사용자 간의 분쟁을 처리해야 합니다.
몇 가지 잠재적/부분적 해결책.
오프체인 시뮬레이션 전략에 직면한 과제는 결코 무시할 수 없지만, 다음 사항을 채택하면 과제를 덜 어렵게 만들 수 있습니다.
1. 후속 거래를 확정합니다.
후속 거래가 최종적이고 수정 불가능하다는 점을 고려하면 수정 및 재시뮬레이션과 관련된 시간 문제가 사라집니다. 수정/재시뮬레이션이 필요 없기 때문에 블록이 게시된 후 범위를 벗어난 증명을 제출할 수 있으며, 이를 통해 두 번째 만료가 필요 없고 미공개 거래 노출에 대한 개인정보 보호 우려도 사라집니다. 가장 큰 단점은 사용자의 선택권이 줄어든다는 것입니다.
2. 모범 사례를 정의하세요.
사용자와 제안자를 위한 일련의 "모범 사례" 지침은 우발적인 중복을 줄이는 데 도움이 될 수 있습니다. 한 가지 방법은 일반적인 거래 유형에 대한 권한 집합에 권장되는 도메인 수를 제공하는 것입니다. 예를 들어, 대부분의 간단한 스왑에 2~4개의 도메인이 있는 권한 집합이 필요하다고 가정해 보겠습니다. 그러면 사용자는 간단한 스왑에 4개 이상의 도메인을 사용하면 우발적인 중복 위험이 높아진다고 추론할 수 있습니다(또는 더 가능성이 높은 경우, 모범 사례 권장 사항을 기반으로 도구를 설계할 수 있습니다).
부록 B: 업프런트 모델.
후속 거래는 사용자의 선택권을 극대화하지만, 후속 문제 및 우발적인 중복 방지와 관련된 설계상의 어려움을 야기합니다. 그러나 사용자가 자신의 거래를 상태 잠금 요청의 일부로 포함하고 해당 거래를 최종적이고 수정 불가능한 것으로 간주함으로써 이러한 어려움을 상당 부분 피할 수 있습니다. 이러한 설계의 주요 단점은 선택권 감소와 MEV 추출에 대한 높은 취약성입니다. 전반적으로 제안자에게 더 친화적인 모델입니다. 하지만 설계의 단순성 덕분에 간략하게 살펴볼 가치가 있습니다.
업프런트 모델 내에서 예상되는 논리적 진행.
1단계) 사용자는 (i) 스냅샷, (ii) 거래, (iii) 우선 수수료를 포함하는 상태 잠금 요청을 보냅니다.
2단계) 제안자는 요청을 받고, 우선 수수료가 적절하게 책정된 경우 거래를 시뮬레이션합니다.
3단계) 제안자는 사용자의 요청에 서명하는 확인 메시지를 반환합니다.
4단계) 제안자는 거래를 블록 템플릿에 잠그고 업데이트된 상태를 네트워크에 브로드캐스트합니다.
5단계) 사용자는 확인 메시지를 받습니다. 이 메시지는 예를 들어 사용자의 거래가 잘못된 스냅샷에 대해 실행되는 경우 제안자를 삭제하는 데 사용할 수 있습니다.
상태 잠금 요청에 트랜잭션 추가.
상태 잠금 권한은 이제 단일 Tip 필드만 사용하고 만료 기간이 없으며 추가 txPayload 필드를 포함해야 합니다.
{
blockNumber:…,
snapShot:[(address, storage slot), (value)…],
Tip:…,
nonce:…,
txPayload:…,
}
업프런트 모델의 일반적인 장점.
1. 움직이는 부품이 적어 디자인이 더 간단합니다.
후속 거래와 관련된 공정한 교환 문제는 증명 위원회와 만료와 같은 이를 해결하는 데 필요한 메커니즘과 함께 제거됩니다.
2. 제안자는 상태 잠금을 허용하기 전에 범위를 벗어난 접근을 차단할 수 있습니다.
제안자에게 유리한 점.
1. 사용자의 의도가 명확하게 드러나면 제안자는 MEV 기회 공간을 더 잘 매핑할 수 있습니다.
2. 제안자는 동일 블록 내의 동일 도메인에 대해 순차적 상태 잠금을 보다 쉽게 제공할 수 있습니다.
3. 단일 팁은 사용자가 후속 조치를 보류함으로써 사후 결제/전액 우선 수수료 지불을 피할 수 없음을 의미합니다.
4. 팁이 하나뿐이면 가격 모델이 더 간단해질 수 있습니다.
제안자에게 불리한 점.
1. 선택권이 감소하면 사용자의 상태 잠금 가치가 낮아지고 제안자의 우선 순위 수수료가 낮아질 수 있습니다.
사용자에게 이점이 있습니다.
1. 더 나은 팁 가격 책정: 선택권 감소와 MEV 노출 증가로 인해 국가 잠금의 가치가 낮아진다고 가정하면, 그에 따른 우선 순위 수수료도 낮아질 것으로 예상됩니다.
2. 후속 거래와 관련된 복잡한 문제(시기, 분쟁 등)가 해소됩니다.
3. 순차적 상태 잠금을 작동시킬 수 있다면 사용자는 더 많은 옵션을 가질 수 있습니다.
사용자에게 단점이 있습니다.
1. 후속 거래가 없다는 것은 선택의 폭이 적다는 것을 의미합니다.
2. 사용자는 MEV 악용에 더 많이 노출됩니다.
3. 4단계에서는 공개되지 않은 거래에 대한 정보를 공개하는 작업이 포함되며, 이로 인해 개인정보 보호 문제가 발생할 수 있습니다.
부록 C: 상태 잠금 사기 및 L1 ZK 연구
상태 잠금과 다른 유형의 제안자 커미트먼트의 주요 차이점 중 하나는 상태 잠금이 실행 후 결과보다는 실행 전 조건에 초점을 맞춘다는 것입니다. 이는 다소 직관에 어긋나지만, 상태 잠금 사기는 전적으로 후속 거래가 실행되기 전에 어떤 일이 발생하는지의 문제임을 의미합니다. 따라서 이 부록의 전반부에서는 몇 가지 예비적인 정의를 검토하여 상태 잠금 사기의 본질을 명확히 하고, 후반부에서는 상태 잠금 사기 증명에 대한 추가 연구를 통해 현재 L1 zkEVM 연구에 어떤 도움을 줄 수 있는지 살펴봅니다.
국가 잠금 사기에 대한 두 가지 정의.
국가 잠금 사기에 대해 생각하는 데는 기본적으로 두 가지 다른 방식이 있습니다. 첫 번째는 "스냅샷 사기" 관점에서 생각하는 것입니다. 두 번째는 "최초 접근 사기"에 초점을 맞추는 것입니다. 이 두 가지 유형의 사기는 국가 잠금 부여를 이해하는 두 가지 다른 방식을 반영합니다.
두 번째이자 더 엄격한 해석에 따르면, 상태 잠금 부여는 사용자의 후속 트랜잭션 T가 T의 권한 집합 P에 지정된 도메인 중 하나에 쓰기 권한을 가장 먼저 부여받도록 약속합니다. T는 "선순위" 또는 "최초 접근 권한"을 가진다고 합니다. T가 원래 상태로 돌아가서 이후 트랜잭션이 P의 특정 도메인에 쓰기 권한을 가장 먼저 부여받더라도, 이전 트랜잭션이 T의 도메인 중 하나에 쓰기 권한을 부여하지 않는 한 "선순위" 약속은 여전히 유효합니다. 간단히 말해서, 예비 정의는 다음과 같습니다.
최초 접근 사기. 최초 접근 사기는 상태 잠금 트랜잭션으로 예약된 도메인에 트랜잭션이 선제적으로 쓰기 작업을 수행할 때 발생합니다.
상태 잠금 부여에 대한 첫 번째, 그리고 약간 덜 엄격한 해석에서는, 최초 접근 약속이 없습니다. 약속은 T가 T의 스냅샷 S에 지정된 도메인-값 쌍 집합에 대해 실행한다는 것입니다. 스냅샷 사기는 T가 T 이전 상태 루트인 Rpre에 대해 실행하고, Rpre에 S가 포함되지 않은 경우(즉, S에 지정된 도메인-값 쌍을 포함하지 못하는 경우) 발생합니다.
최초 접근 사기와 스냅샷 사기의 구분은 단순한 개념적 차원을 넘어, 사기 입증에 있어 실질적인 영향을 미칩니다. 예비적 정의는 다음과 같습니다.
스냅샷 사기. 스냅샷 사기는 어떤 상태 잠금 트랜잭션 T, 도메인 D, 그리고 32바이트 값 V에 대해, T에 대한 스냅샷이 D가 T 이전 상태 루트 Rpre에서 V에 매핑되도록 지정하고, Rpre가 D가 어떤 값 V*에 매핑되도록 하는 경우 발생합니다. 여기서 V* ≠ V입니다.
스냅샷 사기를 증명하려면 먼저 T가 실행된 T 이전 루트인 Rpre를 도출해야 합니다. 머클 포함 증명을 사용하여 Rpre 하에서 D가 V*에 매핑됨을 보여줄 수 있습니다(예: storageRoot에 대한 계정 수준 MPT 경로를 사용한 후, storageRoot 하에서 D(V*)에 대한 MPT 경로를 사용). D가 Rpre 하에서 V*에 매핑됨을 보이면 T가 실제로 D(V*)를 확인했음을 의미합니다. 마지막으로 V* ≠ V임을 보여주는데, 여기서 V는 서명된 상태 잠금 부여에서 가져온 것입니다.
최초 접근 사기를 증명하기 위해서는 다른 트랜잭션 T*가 T보다 먼저 실행되어 T의 도메인 중 하나에 데이터를 썼다는 것을 보여줘야 합니다. 이는 블록의 transactionsRoot 트라이에서 T*와 T의 상대적 위치를 증명하고, 실행 추적에서 T*가 T의 권한 집합에 있는 도메인에 데이터를 쓴 단계까지 재실행함으로써 가능합니다. 스냅샷 사기와 달리, T가 실행된 Rpre를 도출할 필요가 없습니다. T가 10번째 트랜잭션이고 T*가 2번째 트랜잭션인 경우, 최초 접근 사기 증명은 스냅샷 사기 증명보다 단계가 적게 필요합니다. 스냅샷 사기 증명은 T 이전의 모든 트랜잭션의 결과를 도출해야 합니다.
상태 잠금 사기에 대한 간략한 논의는 필연적으로 많은 세부 사항을 생략합니다. 예를 들어, T*가 T의 도메인 중 하나에 동일한 값(no-op SSTORE)을 쓰면 최초 접근 사기는 발생하지만 스냅샷 사기는 발생하지 않습니다. 이는 페널티가 부과되기 전에 두 가지 유형의 사기 모두 발생해야 한다는 요구(또는 최초 접근 사기를 예약된 도메인에 "쓰는" 것이 아니라 "수정하는" 것으로 정의하는 것)의 이유가 될 수 있습니다. 그럼에도 불구하고, 우리의 목적은 단순히 상태 잠금 사기의 기본 개념 모델을 명확히 하는 것입니다.
State Lock 사기 방지가 L1 ZK 연구에 어떻게 도움이 될 수 있는가.
이더리움 재단은 이더리움이 궁극적으로 " 스택의 모든 레벨에서 " ZK 기반을 구축하는 것이 최선의 방향이라고 생각합니다. 이러한 맥락에서, 상태 잠금 연구가 이러한 목표를 어떻게 지원할 수 있는지 주목할 필요가 있습니다. 본 논문의 후반부에서는 ZK 기반 설계를 통해 상태 잠금 분쟁을 어떻게 해결할 수 있는지 살펴보겠습니다. ZK 기반 설계에서는 실행 추적을 오프체인에서 재실행하고 간결한 증명을 온체인에서 검증하여 프로토콜 내 재실행에 따른 막대한 비용을 피할 수 있습니다. (물론 BAL은 온체인에서 분쟁을 처리하는 비용을 크게 절감할 수 있는 잠재력을 가지고 있습니다.)
상태 잠금 사기 증명은 고유한 연구 기회를 창출할 수 있는 잠재력을 가지고 있습니다. 예를 들어 , 상태 잠금 사기 증명은 마지막 상태 잠금 트랜잭션 이후에는 아무것도 다시 실행할 필요가 없습니다. 제안자가 상태 잠금 트랜잭션의 시퀀싱을 우선시한다는 그럴듯한 가정(즉, 제안자가 트랜잭션을 블록 상단에 배치한다는 가정)에 따르면 사기 증명은 전체 블록의 일부만 처리하면 됩니다. 반면, Succinct Labs의 SP1 Hypercube 와 같은 시스템은 일반적으로 하위 블록 증명을 생성한 다음 이를 집계하여 전체 L1 블록을 목표로 합니다. 제안자가 상태 잠금 트랜잭션을 블록 상단에 배치하면 분쟁은 전체 블록이 아닌 초기 슬라이스 또는 "프리픽스"만 증명하면 되므로 사기 증명 회로가 전체 L1 zkEVM 증명보다 상당히 작아집니다.
예를 들어, 앞서 언급했던 첫 번째 접근 사기 사례를 살펴보겠습니다. 범위를 벗어난 트랜잭션 T*가 블록의 두 번째 트랜잭션인 경우, 회로는 두 트랜잭션만 재실행하고 증인(witness) 내부에서 T* 이전의 중간 루트를 재구성합니다. 더 일반적으로, T*가 *i-*번째 트랜잭션인 경우, 첫 번째 접근 사기 방지 회로는 i개의 트랜잭션을 재실행하고 i-1개의 중간 루트를 재구성합니다. 전체 블록 zkEVM 용어로 표현하면, 첫 번째 접근 사기 방지는 여러 접두사에 대한 재귀적 집계/구성이 필요하지 않으므로 전체 블록이 아닌 작은 단일 접두사를 증명하는 것과 유사합니다. 마찬가지로, 스냅샷 사기 방지는 일반적으로 첫 번째 접근 사기 방지보다 더 많은 제약 조건이 필요하지만, 회로의 크기는 여전히 단일 접두사 증명 수준입니다.
상태 잠금 사기 증명은 작고 집중적인 회로를 가지고 있기 때문에 새로운 가젯 수준의 최적화를 연구할 수 있는 실질적인 기회를 제공할 수 있습니다. 한 가지 아이디어는 동일한 Keccak 라운드를 여러 독립적인 해시(예: RLP 인코딩된 MPT 노드, 저장 키 유도)에 걸쳐 배치하는 회로를 프로토타입으로 만드는 것입니다. 이렇게 하면 증명자가 여러 개의 "좁은" 단계 대신 "넓은" 단계 하나를 실행하게 됩니다. 상태 잠금은 이러한 종류의 라운드 "퓨징" 또는 라운드 배치에 적합합니다. 범위를 벗어난 스크리닝은 종속성을 제거하기 때문에, 상태 잠금은 EVM 순서를 위반하지 않고 여러 해시를 병렬로 실행하는 데 필요한 독립성을 이미 구현하고 있습니다. 그 결과 회로 행/단계가 줄어들어 증명 시간이 단축되고 증명 크기도 줄일 수 있습니다. 비록 추측적인 측면이 있지만, 해시 라운드 "퓨징"은 상태 잠금 회로가 L1 해싱 핫스팟으로 이어지는 결과를 통해 테스트/검증할 수 있는 구체적인 최적화의 한 예입니다.
상태 잠금 사기 증명은 증명 효율성을 측정하고 유용한 경험적 데이터를 생성하는 일종의 "테스트 랩" 역할을 할 수도 있습니다. 짧은 "접두사"와 상대적으로 작은 접촉 슬롯 집합 덕분에 회로가 간단하여 열린 슬롯당 시간, MPT 경로당 위트니스 바이트 등과 같은 구성 요소 비용을 노출할 수 있습니다. 전체 블록 증명에서는 이러한 신호가 다른 데이터(예: EC/KZG 연산, 위트니스 I/O, 집계)와 혼합되는 경향이 있어 구성 요소당 정확한 숫자를 복구하기가 더 어렵습니다. 또한, 상태 잠금 사기 증명은 "홈" 증명기 하드웨어에서 실행될 만큼 충분히 작을 수 있으며, "홈" 증명기의 에너지/RAM/GPU 프로필과 같은 가치 있는 경험적 데이터를 수집할 수 있습니다. 이런 방식으로 상태 잠금 사기 방지 연구는 소규모 증명을 사용하여 추정하고 관련 전체 블록 작업 부하 분포(예: SSTORE/SLOAD 오프닝)로 외삽할 수 있는 세분화된 구성 요소 수준 측정을 제공하여 전체 블록 벤치마킹을 보완할 수 있습니다.
여기서 한 가지 주의할 점은 슬래싱 위험으로 인해 상태 잠금 사기가 극히 드물게 발생한다는 것입니다. 그렇다고 해서 사기 증명이 거의 요청되지 않는다는 것을 의미하지는 않습니다. 사용자 관점에서는 예상치 못한 거래 행위가 사기 요청의 주요 원인입니다. 상태 잠금은 실행 전 조건만 약속하고 결과는 보장하지 않기 때문에 예상치 못한 행위가 드물지 않을 수 있습니다. 실제 사기가 의심되는 사기보다 훨씬 덜 흔하다고 가정할 때, 대부분의 사기 증명은 명목상의 목적과는 정반대의 역할을 할 것입니다. 즉, 사기가 발생하지 않았음을 확인하는 "정직" 증명 역할을 할 것입니다. 실제로 제안자는 요청 시 이러한 "정직" 증명을 제공할 유인을 갖게 되며, 특히 제3자가 비공식적으로 오프체인으로 검증할 수 있다면 더욱 그렇습니다. 시의적절하고 효율적인 "정직" 증명을 제공해야 할 필요성은 자연스럽게 연구 및 최적화에 대한 유인을 창출할 것입니다.
마지막으로, 여기서 제안하는 L1 ZK 연구의 잠재적 이점은 상태 잠금에만 국한되지 않는다는 점을 언급할 가치가 있습니다. 실행 컨텍스트/결과를 증명하는 사기 증명을 요구하는 모든 실행 사전 확인 프로토콜은 이를 활용하여 L1 ZK 연구의 수준을 잠재적으로 향상시킬 수 있습니다.
