Beam Sync: Ethereum 노드를 동기화하는 새로운 방법
편집자 주: 이 기사의 출처:이더리움 애호가(ID: ethfans)이더리움 애호가(ID: ethfans)
, 저자: Jason Carver, 번역 및 교정: Chen Liang & A Jian, Odaily의 승인을 받아 재인쇄됨.
텍스트
노드 동기화 환경을 개선하는 이유는 무엇입니까?
얼마나 많은 사람들이 온체인 애플리케이션과 상호 작용하기 위해 여전히 Infura(Metamask, Gnosis-Safe 등을 통해)를 사용하고 있는지 생각하면 약간 오싹해집니다. Infura의 서비스는 훌륭하지만 대부분의 사용자가 자신의 노드를 실행하지 않는 경우 분명히 옳지 않습니다. 가장 유능하고 의욕이 넘치는 개발자라도 Infura에 대한 의존도를 완전히 없앨 수는 없습니다. 이 시점에서 우리는 아직 이더리움의 "자체 검증" 비전의 상당 부분을 완료하지 못했습니다.
우리 팀은 이러한 추세를 역전시키기 위해 자신의 역할을 다하고자 합니다. 우리의 임무는 특히 취미 생활자, 연구원 및 개발자가 운영하는 네트워크의 노드 수를 가능한 한 많이 늘리는 것입니다. 자체 노드를 실행하지 않는 이유를 물었을 때 대답은 "클라이언트 소프트웨어를 설치하고 블록체인을 동기화하려고 시도했지만 동기화되지 않는 것 같습니다. 다른 일이 있어서 중지했습니다. 하다."
첫 번째 레벨 제목
기존 동기화 방법
보조 제목
Full Sync(완전 동기화 방식)
완전히 동기식 접근 방식은 제네시스 블록 이후 모든 블록을 실행하는 것입니다. 제네시스 블록은 초기 제네시스 상태를 표시합니다(상태의 내용에는 계정 잔액, 계약 바이트 코드, 계약 저장 내용 등이 포함됨). 소위 "실행 블록"은 블록이 다운로드될 때마다 이전 상태를 읽고 새 상태가 생성되고(블록 내용에 따라) 새 상태가 상태 루트를 확인하는 데 사용됨을 의미합니다. 블록 헤더(블록 블록이 유효한 블록이 아닌지 확인하기 위해). 전체 동기화는 이더리움 메인넷에서 매우 느리고 네트워크가 노후화됨에 따라 전체 동기화 방법을 사용하여 최신 블록에 동기화하는 데 시간이 점점 더 오래 걸립니다. 그래서 사람들은 "빠른 동기화" 방법을 개발했습니다.
보조 제목
Fast Sync(빠른 동기화 방식)
빠른 동기화가 시작 블록을 실행하기 전에 필요한 블록 상태에는 계약 바이트코드, 계정 및 계약 스토리지 콘텐츠가 포함됩니다. 트랜잭션을 실행할 때 이러한 값을 읽어야 할 수도 있습니다. 따라서 빠른 동기화 방식을 사용하려면 다른 피어에서 블록이 시작되기 전에 상태의 스냅샷을 얻어야 합니다. 스냅샷은 상태 루트 해시 값으로 표시되며 소위 상태 루트 해시 값은 모든 상태 콘텐츠의 해시 머클 트리 루트 값입니다. 노드는 이 상태 루트 해시를 사용하여 다른 피어에서 다운로드한 상태 데이터가 블록의 광부가 주장한 상태와 일치하는지 확인합니다.
빠른 동기화 방법이 필요한 모든 상태를 다운로드한 후에는 노드에 이미 트랜잭션을 실행하는 데 필요한 모든 데이터가 있음을 의미합니다. 그러면 이 시점부터 노드는 완전 동기 모드로 전환할 수 있으며 시작 블록 이전에 전체 동기화 프로세스를 완료한 노드와 마찬가지로 시작 블록부터 블록을 하나씩 실행할 수 있습니다.
보조 제목
기타 방법
다른 빠른 동기화 방법에는 Warp Sync 및 현재 검증되지 않은 일부 동기화 방법이 포함됩니다. 보다 추상적인 수준에서 이들은 모두 다른 형태의 빠른 동기화 방법에 속합니다. 또한 이러한 다른 동기화 방법의 원리를 이해하더라도 빔 동기화 전략을 이해하는 데 도움이 되지 않으므로 이러한 동기화 원리는 우리 기사의 초점이 아니며 나중에 설명하겠습니다.
첫 번째 레벨 제목
빠른 동기화 방법은 얼마나 빠릅니까?
빠른 동기화 방법은 현재 메인 네트워크 운영 환경에서 몇 가지 문제에 직면해 있습니다. 동기화는 많은 데이터, 심지어 100GB 이상의 데이터를 다운로드해야 하기 때문에 위의 두 번째 단계인 "Get All State"에서 가능할 수 있습니다. 피규어 '는 오랫동안 붙어있을 것입니다.
30분 안에 모든 상태 데이터를 다운로드할 수 없는 경우(스포일러 경고: 정말 완료할 수 없음) 피벗(pivot)을 수행해야 합니다. 즉, 새 부트 블록으로 변경하고 동기화를 다시 시작해야 합니다. 0부터는 아니지만 블록을 다운로드하고 확인하는 시간도 늘어납니다.
첫 번째 레벨 제목
개요
빔 싱크 방식
보조 제목
빔 동기화 방식은 고속 동기화 방식을 직접 개선한 결과로, 두 동기화 방식의 차이점은 빔 동기화 방식은 초기에 스타트업 블록을 직접 실행하고, 로컬 데이터베이스에 없는 상태 데이터만 요청한다는 점이다. , 그리고 입력 상태와 출력 상태를 로컬에 저장합니다. 블록을 실행한 후 다음 블록으로 동기화하고 프로세스를 반복하며 필요에 따라 누락된 데이터를 요청합니다.
시간이 지남에 따라 누락된 데이터는 점점 줄어들 것입니다. 특정 상태에 액세스하지 않으면 클라이언트는 이를 요청하지 않으므로(따라서 상태 데이터의 이 부분을 가져오지 않음) 백그라운드에서 다른 프로세스를 실행하여 이러한 간격을 채웁니다. 이 백필 프로세스를 통해 Beam Sync는 결국 모든 상태 데이터를 가져와서 로컬에 저장하고 노드는 완전히 동기화된 상태로 전환할 수 있습니다.
각 블록을 실행하는 데 필요한 데이터 세트를 "블록 증인"이라고 합니다. 머클 트리의 구조 덕분에 완전한 상태를 다운로드하지 않고도 증인 데이터가 실제로 이 상태에서 가져온 것임을 증명할 수 있습니다(번역자 주: 소위 "머클 증명"입니다).
보조 제목
간단히 하기 위해 "블록 감시 데이터 크기"를 사용하여 블록을 실행하는 데 필요한 데이터 요소의 수를 나타냅니다. 이러한 데이터 요소는 기본 계정 상태 트리의 노드, 계약 스토리지 트리의 노드 또는 계약의 완전한 바이트코드일 수 있습니다(번역자 주: 여기서 "상태 트리", "저장 트리"는 모두 머클 트리 구조 데이터).
블록 감시 데이터 크기를 분석하는 것은 빔 동기화 방법의 성능을 이해하는 데 중요합니다. 빠른 동기화 방법은 첫 번째 블록(즉, 시작 블록)을 실행하기 전에 모든 상태 데이터를 다운로드해야 하는 반면, Beam 동기화는 다운로드된 블록 감시 데이터가 전체 상태의 1/3을 포함하는 경우 한 블록의 감시 데이터만 다운로드하면 됩니다. 하나, 그러면 Beam Sync가 Fast Sync보다 약 3배 효율적으로 실행됩니다.
따라서 다음 단계는 메인넷 증인 데이터가 실제로 얼마나 큰지 확인하는 것입니다. 직접적인 결론을 내리기에는 너무 이르지만 초기 테스트 결과는 3000개의 상태 트리 노드가 합리적인 추정치임을 시사합니다(신뢰 수준 90%). 메인 네트워크의 총 상태 정보는 3억 개 이상의 트리 노드를 가지고 있습니다.
보조 제목
Beam sync 속도 개선
"실행 시작" 시간이라는 새로운 기준을 정의해 보겠습니다. 이것은 빈 데이터베이스로 노드를 시작하여 가장 최근 블록의 전체 가져오기를 완료하는 데 걸리는 시간입니다.
Beam이 3000개의 상태 트리 노드만 다운로드해야 하고 빠른 동기화가 3억 개의 트리 노드를 다운로드해야 하는 경우 Beam Sync 방법의 속도 제한을 결정할 수 있습니다. 메인넷을 동기화할 때 "실행 시작" 시간일 수 있습니다. 최대 100,000배 부스트를 받으세요!
그러나 Beam Sync 접근 방식은 실제로 100,000배 개선을 달성하지 못하는 경우가 많습니다. 이유에는 다음이 포함되지만 이에 국한되지는 않습니다.
블록 감시 데이터는 요청 시 결정됩니다. 즉, 어떤 상태 데이터가 필요할지 미리 예측할 수 없습니다(하나의 데이터를 수신한 후에야 다음 필수 데이터가 무엇인지 결정할 수 있음). 따라서 피어 노드에서 데이터를 요청할 때 한 번에 하나의 상태 데이터만 요청할 수 있습니다. 반대로 Fast Sync는 한 번에 최대 384개의 트리 노드를 요청할 수 있으므로 Beam Sync가 피어 네트워크 대기 시간에 더 민감해집니다.
지연 시간이 짧은 고품질 동기화 노드를 찾는 데는 시간이 걸립니다. 솔직히 말해서 어떤 종류의 피어 노드를 만나게 될지는 진정한 무작위 이벤트입니다.
빠른 동기화 방법과 달리 빔 동기화 방법은 시작 블록 이후에도 블록 상태를 계속 다운로드하므로 블록 가져오기 시간도 느려집니다. 이에 대해 어느 정도 직관이 있는 경우 블록 감시를 수집하는 평균 시간이 블록을 생성하는 평균 시간보다 길면 문제가 악화된다는 것을 알 수 있습니다.
보조 제목
빔 동기화 지연
블록 감시 데이터 수집 지연이 점차 증가할 수 있으며 Beam 동기화 노드가 5분 지연됨을 알 수 있습니다. 즉, 로컬에 있는 최신 블록은 실제로 5분 전에 전체 네트워크에서 생성된 블록입니다. 즉, RPC가 현재 노드 계정 잔액을 호출하면 노드가 5분 전에 잔액을 피드백합니다.
Beam Sync Pivot
일화 테스트에서 지연 시간은 일반적으로 1분에서 20분까지 다양합니다. 운 좋게도 우리는 지연된 블록 동기화에서 복구하기 위한 몇 가지 요령을 가지고 있으며 실제로 일반적으로 말하면 더 많이 뒤처질수록 더 잘 복구할 수 있으며 이로 인해 지연 시간이 크게 변동됩니다. 주기가 반복됩니다.
블록이 뒤에 있는 경우 더 빨리 따라잡을 수 있는 한 가지 이유는 여러 블록에 대한 증인 데이터를 사전에 동시에 생성할 수 있기 때문입니다. 결국, 뒤처진 경우에만 이러한 미래 블록을 활용할 수 있습니다. 물론 필요한 블록 데이터를 수집하는 데 걸리는 시간이 항상 블록 생성 시간을 초과한다면 블록체인의 성장에 점점 더 뒤처지게 될 것이라는 데는 의심의 여지가 없습니다. 이것을 계획하십시오.
보조 제목
빔 동기화의 피벗 메커니즘은 빠른 동기화와 비슷합니다. 노드가 건너뛸 일련의 블록을 선택하고 체인 상단 근처의 새 블록 헤더를 선택한 다음 빔 동기화가 다시 시작되고 노드가 정확히 일치하지 않습니다. 처음부터 동기화하지만 여전히 이전 동기화의 모든 데이터를 가지고 있습니다.
자, 실제 상황이 어떤지 봅시다.
첫 번째 레벨 제목
Trinity 클라이언트의 빔 동기화
보조 제목
프로토타입 발표
Trinity 클라이언트의 새로운 알파 버전이 지난 주에 발표되었으며 이 버전에는 하이엔드 하드웨어에서 실행되는 Beam의 동기화 방법 프로토타입이 포함되어 있습니다.
참고: 블록 가스 한도를 8M에서 10M으로 올리면 평균 지연 시간이 증가하는 것으로 보이며 이스탄불 업그레이드는 블록체인에 상태 데이터를 작성하는 데 필요한 가스 소비를 증가시키기 때문에 지연 시간을 줄일 수 있습니다.
현재 트리니티는 아직 알파 버전이고 최신 버전은 아직 문제가 많습니다. Trinity 클라이언트를 설치하려면 추가 작업이 필요했고 명령줄 출력이 엉망이었습니다. 따라서 Trinity는 현재 호기심이 많고 가지고 노는 것을 꺼리지 않는 개발자와 연구원만 사용할 수 있습니다.
해결되지 않은 문제는 기본적으로 일일 개발에서 노출되므로 이러한 문제는 "백그라운드 로그의 버그"입니다. 이 시점에서 Beam Sync가 달성할 수 없는 꿈이 될 것이라고 걱정하는 사람은 아무도 없다고 해도 무방합니다. 빔 동기화에 대한 이러한 확신은 새로운 것입니다. 하지만 한 달 전과 같이 앞으로 갑자기 해결해야 할 알려지지 않은 문제가 있을 수 있다고 생각합니다!
남은 일
기본 디버깅 및 구현 작업 외에도 아직 해야 할 다른 작업이 많이 있습니다. Trinity는 아직 상태에 대한 백필 메커니즘을 구현하지 않습니다(예: 시작 블록 이전에 이전 이벤트, 트랜잭션 및 데이터 다운로드). 현재 스위칭 메커니즘을 활성화하는 유일한 방법은 Trinity를 다시 시작하는 것이며, 빔 동기화 방법에 필요한 최소 하드웨어 구성은 알려져 있지 않습니다(관련 데이터 수집에 도움을 주신 모든 분을 환영합니다).
위의 모든 문제는 활발한 R&D 중에 있으며, 이는 이더리움 재단의 이러한 노력에 대한 후원과 지원 덕분에 트리니티의 많은 작업 중 하나에 불과합니다.
첫 번째 레벨 제목
Beam Sync의 새로운 점은 무엇입니까?
빔 동기화 방법은 다른 이론과 마찬가지로 이전 연구 작업을 기반으로 합니다. 최신 상태를 다운로드하고 이전 블록의 실행을 건너뛰어 동기화 속도를 높이는 방법(빠른 동기화 방법)은 우리가 발명한 것이 아닙니다. 실행 속도를 높이기 위해 완전한 상태 대신 증인 데이터에 의존하여 블록을 실행하는 방법은 우리가 발명한 것이 아닙니다.자세한 내용은 상태 비저장 클라이언트를 참조하십시오.
