소개: EVM 바이트코드의 머켈화
편집자 주: 이 기사의 출처는Unitimes（ID：Uni-times）편집자 주: 이 기사의 출처는
개요: 상태 비저장 클라이언트는 블록 감시의 일부로 블록에서 호출된 스마트 계약 코드를 보내야 합니다. 계약 코드는 상태 비저장 블록 대역폭 오버헤드에 두 번째로 큰 기여를 합니다. 코드 머클라이제이션은 이러한 오버헤드를 줄이는 데 도움이 되는 것으로 여겨집니다. 이 글은 컨트랙트 코드를 블록으로 분할하고, 이 블록들을 Merkleize(작성자 주: 이 블록들을 Merkle 트리로 만드는 것을 말합니다)하고 트랜잭션 실행에 필요한 블록만 전송하는 방법에 대해 자세히 설명합니다. 최근 메인넷 블록으로 수행한 실험에 따르면 이 접근 방식이 총 40-60%의 코드 전송을 절약한다는 것을 알 수 있습니다.
보조 제목
상태 비저장 블록이 큽니다.
상태 비저장 모델에서 (적어도 일부) 노드는 상태를 저장할 필요가 없으며 다른 노드(예: 채굴자)에 의존하여 필요한 모든 상태(계약 코드 포함) 및 이러한 상태의 유효성을 증명하는 Merkle 증명을 블록으로 패키징합니다. 이것은 이전보다 훨씬 더 큰 네트워크 대역폭을 의미합니다. Alexey Akhunov와 turbo-geth[5] 팀은 과거 메인넷 블록의 블록 증인 크기를 측정하기 위한 실험을 해왔습니다. 다음은 마지막 50,000개 블록에 대한 측정값입니다. 빨간색 선은 블록 감시 크기의 두 번째로 큰 소스인 상태 비저장 블록에서 전송해야 하는 계약 코드의 양을 추적합니다. 이더리움이 현재 헥스 트라이에서 바이너리 트라이로 마이그레이션하면 이러한 증인의 해시 부분이 ~3배 줄어들어 계약 코드가 증인 크기의 주요 소스가 됩니다.
github[6]의 데이터. 50,000개의 최근 메인넷 블록에 대한 상태 비저장 블록 증인 구성을 보여주는 그래프. 이 값은 128 블록의 창에 대한 이동 평균입니다.
보조 제목
전체 코드를 보낼 필요가 없습니다.
이것이 어떻게 작동하는지 정확히 보기 위해 새 계약이 배포되는 것을 상상해 봅시다. 우리는 계약 코드를 스캔하고 기본 블록[7]을 식별합니다(알고리즘 [8] 참조)(저자의 메모, 기본 블록은 순차적으로 실행되는 코드 조각으로 이해할 수 있습니다). 클라이언트는 JUMPDEST 분석을 위해 코드를 한 번만 스캔하면 되므로 높은 오버헤드가 발생하지 않습니다. 이러한 기본 블록에는 두 가지 특성이 있습니다.
이미지 설명
가상 바이트코드의 기본 블록
각 기본 블록은 인덱스 0 또는 JUMPDEST에서 시작합니다. 이는 상태 비저장 클라이언트가 JUMPDEST 분석을 안전하게 수행할 수 있도록 하기 위한 것입니다(자세한 내용은 나중에 설명).
각 기본 블록은 제어 흐름을 변경하지 않습니다(예: JUMP 없음). 따라서 우리는 일단 기본 블록을 실행하기 시작하면 끝까지 실행되거나 가스가 고갈될 것임을 확신할 수 있습니다. 이 솔루션이 더 효율적이라고 가정하지만 비교를 위해 대안을 테스트하지는 않았습니다.
효율성을 위해 인접한 기본 블록은 각 기본 블록의 최소 길이가 128바이트가 될 때까지 병합됩니다(이는 구성 가능한 매개변수임). 그런 다음 첫 번째 바이트의 인덱스를 키로 사용하여 트리에 삽입됩니다. 클라이언트는 결국 계약을 기록하는 새로 생성된 계정에 이 트리의 루트를 저장합니다. 아래와 같이 코드 트리는 실제로 상태 트리(저장소 트리와 유사)의 하위 트리가 됩니다.
계약을 호출하는 트랜잭션을 제출하여 이를 테스트해 보겠습니다. 채굴자는 트랜잭션을 실행하고 실행 중에 터치된 블록을 표시합니다(이 경우 블록 1과 3). 블록을 게시할 때 광부는 계약 계정의 상태 증명과 코드 블록 터치의 터보 증명을 포함합니다[9].
이미지 설명
블록을 수신한 후 상태 비저장 클라이언트는 계약이 상태의 일부이고 균형, 난스 값, 상태 루트 및 코드 루트와 같은 올바른 속성을 가지고 있는지 확인할 수 있습니다. 그런 다음 코드 루트에 대해 코드 블록과 해당 키의 유효성을 검사할 수 있습니다. 위의 정보는 클라이언트가 이러한 블록에서 바이트 코드의 일부를 재구성하고 다른 블록을 비워두기에 충분합니다. 우리가 사용하는 블록 분할 알고리즘에 따르면 클라이언트는 모든 블록(첫 번째 블록 제외)이 JUMPDEST로 시작한다는 것을 알고 있으므로 점프를 안전하게 수행할 수 있습니다.
보조 제목
실험
실험
보조 제목
어디로 가야
어디로 가야
각 블록의 최소 길이는 구성 가능한 매개변수입니다(위에서 128바이트로 설정). 이 매개변수를 수정하면 블록 감시의 크기에 두 가지 반대 효과가 있습니다. 예를 들어 32바이트로 줄이면 블록 세분성이 더 미세해져 전송해야 하는 총 코드 양이 줄어듭니다. 그러나 동시에 트리 트리의 깊이도 증가하여 결국 증명에 필요한 해시 수가 증가하게 됩니다. 다음 단계는 가장 공간 효율적인 값이 있는지 확인하기 위해 최소 블록 크기 설정을 보다 철저히 분석하는 것입니다. 최소 블록 크기의 값에 관계없이 16진수 트리에서 이진 트리로 전환하면 증명에 필요한 해시가 1/4로 줄어들고(여기 [11] 참조) 블록 증인의 크기가 더 줄어듭니다.
이 프로토타입의 경우 코드를 기본 블록으로 분할하기로 선택했지만 일부는 더 간단하고 일부는 더 복잡한 다양한 다른 분할 알고리즘이 존재합니다. 가장 쉬운 방법은 코드를 고정 크기 블록(예: 블록당 32바이트)으로 나누는 것입니다. 현재 이 솔루션의 유일한 문제는 PUSH 데이터 및 JUMPDEST 분석과 관련된 것입니다.
이를 기반으로 확장: 임의의 경계에서 바이트 코드를 분할하면 PUSH opcode의 피연산자와 향후 도입되는 다른 멀티바이트 opcode가 블록을 수신하는 클라이언트에 의해 JUMPDEST(0x5b)로 오인될 수 있습니다. 아래와 같이 완전한 코드를 가진 클라이언트는 JUMP가 유효하지 않음을 학습하고(0x5b는 PUSH1의 피연산자이므로) 실행을 중지할 수 있습니다. 그러나 블록 6과 8은 수신하지만 블록 7은 수신하지 않는 클라이언트는 계약을 다르게 구문 분석하는 위치 41로 이동합니다. 나중에 이 문제를 피하고 임의의 경계를 지원하는 체계에 대해 간단히 언급할 것입니다.
이 문제를 해결하기 위해 Martin Holst Swende는 각 블록에 메타데이터를 추가하여 헤더의 몇 바이트가 PUSH의 피연산자인지 지정하도록 제안했습니다. 그런 다음 검증자는 JUMPDEST 분석 중에 이러한 바이트를 건너뛸 수 있습니다. Alexey가 탐색하고 있는 또 다른 방법은 EVM에서 동적 점프를 비활성화하는 것입니다(적어도 코드를 머클라이제이션하려는 계약의 경우). 코드 실행 중 매번이 아니라 배포 시 한 패스에서 정적으로 점프를 분석할 수 있습니다. Alex Beregszaszi는 계약 제어 흐름 그래프를 사용하면 Merkelization을 더 잘 안내할 수 있다고 제안했습니다. 한편 Christian Reitweissner는 계약의 제어 흐름 그래프에서 Merkleized DAG가 생성되는 실행 증명 방식을 제안했습니다. 나는 이 기사에서 그의 생각을 객관적으로 평가할 수 없으며 그가 앞으로 더 많은 설명을 할 수 있기를 바랍니다.
결과는 서로 다른 분할 알고리즘에 대해 무시할 수 있는 효율성 향상만 표시할 수 있습니다. 이 경우 가장 간단한 알고리즘이 가장 현명한 선택이 됩니다. 좋은 소식은 초기 데이터에서 상태 비저장 블록으로 전송되는 코드의 양을 크게 줄이는 알고리즘이 하나 이상 있다는 것입니다.
원본 링크:
원본 링크:
참조 링크:
