0에서 1까지: 이더 이더리움 Shapella 업그레이드 이해하기

avatar
Foresight News
01-10
이 기사는 기계로 번역되었습니다
원문 표시
상하이 업그레이드의 주요 내용은 EIP-4844를 제외한 스테이킹 출금 및 EOF 오픈입니다.

작성자: Shiqi

TL;DR

  • 상하이 업그레이드의 주요 내용은 철수이며 EIP-4844는 상하이 업그레이드에 포함되지 않습니다.
  • 철수
  • 인출은 적극적으로 시작할 필요가 없으며 매일 115,200명의 검증인에 대해 인출이 수행될 수 있습니다.
  • "부분 탈퇴"와 "전체 탈퇴"라는 두 가지 규칙이 있으며, 이는 서로 다른 조건에 해당하며 대부분의 탈퇴는 "부분 탈퇴"입니다.
  • "부분 출금"은 검증인의 수입을 인출합니다. 2년간의 스테이킹으로 인해 비콘 체인에 많은 수입이 축적되었습니다. 따라서 잠금 해제 후 처음 4일 동안 잠금 해제 금액이 가장 큽니다. 인출" "은 수입 + 약속된 32 ETH이며 동시에 인출됩니다.
  • 이상적인 조건에서는 업그레이드 후 첫날 약 40만 ETH, 둘째 날 약 30만, 셋째 날 약 18만, 넷째 날 약 6만 ETH가 언락될 것으로 예상된다. 처음 4일은 "부분 출금"으로 이루어집니다. 5일차부터 모든 검증인은 기본적으로 출금을 경험했으며 대부분의 노드 수입이 출금되었습니다. 따라서 5일차부터 주요 출금 소스는 다음과 같습니다. "모든 인출", 이 숫자는 흐름 계수 제한에 의해 간접적으로 제한됩니다.
  • 정확하게 말하면, 유동성한도계수는 매일 처리할 수 있는 '전체출금' 횟수를 제한하는 것이 아니라, 매일 '전체출금' 조건을 충족할 수 있는 횟수, 즉 대량이 있을 경우를 의미한다. 상하이 업그레이드 전 요구 사항을 충족하는 검증인의 수 "모든 출금" 규칙이 채택되더라도 예상보다 훨씬 더 많은 양의 ETH가 약속되지 않을 가능성이 있습니다.
  • EOF
  • EOF는 새로운 계약 표준과 몇 가지 새로운 opcode를 도입하는 EVM의 업그레이드입니다. 업그레이드 후 EVM은 버전 제어를 수행하고 동시에 여러 계약 규칙 세트를 실행할 수 있습니다.
  • EOF를 사용하면 EVM은 반복 시 향후 호환성에 대한 요구로 인해 더 이상 제한되지 않습니다. 업그레이드의 난이도가 낮기 때문에 향후 Ethereum EVM이 더 자주 업그레이드될 수 있습니다.
  • 빈번한 EVM 반복으로 인해 zkEVM과 같은 EVM 호환 가상 머신에 대한 요구 사항이 높아질 수 있습니다. 버전을 유지하려면 EOF 업데이트를 자체 VM으로 자동 변환하는 기능을 갖춘 다른 EVM 호환 VM이 필요할 수 있습니다. .

Ethereum Shanghai 업그레이드에 대해 알아보기

상하이 업그레이드란 무엇인가요?

상하이 업그레이드는 이더리움 경영진의 다음 하드포크입니다. 이미 콘스탄티노플 업그레이드, 이스탄불 업그레이드, 베를린 업그레이드, 런던 업그레이드 및 파리 업그레이드(병합)를 경험했습니다. EIP-1559는 채굴자의 소득구조를 바꾸고, Merge는 이더리움의 운영 메커니즘을 바꾸는 등

비콘체인(Beacon Chain) - 2년간의 합의계층 연습생

2020년 12월 이더리움은 비콘 체인을 도입했습니다. 이후 이더리움은 실행 계층과 합의 계층을 담당하는 하나의 체인에서 실행 계층 합의 계층을 담당하는 두 개의 병렬 체인으로 전환되었으며, 이는 PoW에서 PoS로의 전환이기도 합니다.

변환 후 합의 레이어는 비콘 체인을 담당하고 실행 레이어는 합병 전 모든 사람이 일반적으로 이더리움 사용자와 상호 작용하는 데 사용하는 이전 이더리움 메인 네트워크, 비콘 체인 및 실행 레이어를 담당합니다. 메인 네트워크는 실행 레이어의 예금 계약 만 전달할 수 있습니다. 즉, 사용자가 실행 레이어의 예금 계약에 ETH를 입금하면 ETH는 비콘 체인에 저장됩니다. 비콘 체인은 실행 계층으로 돌아갈 방법이 없으며 예금 계약의 ETH를 인출할 수 없습니다.

참고: 예금 계약은 ETH 메인 네트워크에 배포된 스마트 계약으로, 최소 1 ETH와 유효한 입력 데이터를 포함하는 모든 거래를 허용하고 이 계약을 사용합니다. 모니터링되는 트랜잭션의 입력 데이터를 사용하여 비콘 체인에 해당 유효성 검사기를 설정합니다.

그러나 비콘 체인은 출시되자마자 데뷔하지 않았고 2년간의 합의 연습생 단계를 거쳤으며 2022년 9월까지 이더리움 메인 네트워크와의 합병을 공식적으로 완료하지 못했습니다. 중간 Beacon 체인은 초기 Phase 0 부터 Altair 업그레이드 , Bellatrix (The Merge라고도 함)까지 여러 번 업그레이드되었으며 마침내 순조롭게 데뷔했으며 이후 Beacon 체인과 Ethereum 메인 네트워크가 통합되었습니다. 하나로 합쳐서 새로운 이더리움을 형성하며, 둘은 Engine API를 통해 통신합니다.

2년 동안 비콘 체인에서 합의 연습생이 되는 과정에서 비콘 체인에 많은 양의 ETH가 축적되었는데, 이는 여전히 빼낼 수 없습니다. 사용자는 일반적으로 이더리움 네트워크에서 작업할 때 자체 실행 ETH를 사용합니다. 레이어의 균형. 따라서 비콘체인 ETH 출금 기능이 구현되어야 하며, 이번 상하이 업그레이드가 이를 기다리고 있습니다.

실제로 상하이 업그레이드는 실행 레이어 업그레이드를 의미하며, 실행을 위해 비콘 체인에서 ETH를 인출하는 기능인 Capella 업그레이드라는 합의 레이어 비콘 체인 업그레이드도 있습니다. 레이어는 Shanghai Upgrade와 Capella Upgrade가 공동으로 완성합니다.

상하이 업그레이드의 핵심 포인트

상하이 업그레이드의 주요 목표는 비콘 체인의 철수 기능을 구현하는 것입니다. 비콘체인 철수와 더불어 EOF(EVM Object Format)도 주요 업그레이드이지만, 정확하게는 메이저이기 때문에 비콘체인 철수 기능 구현을 지연시키지 않기 위해 EOF 업그레이드가 필요합니다. 연기될 수 있으며 주로 그의 진행 상황에 따라 달라집니다.

EIP-4844는 많은 주목을 받고 있는 또 다른 중요한 업그레이드입니다. 이더리움에 큰 의미가 있고 비콘 체인 출금 기능 구현을 지연시킬 수도 있기 때문에 EIP-4844는 다음 칸쿤 업그레이드(상하이)에 배치되는 것으로 확인되었습니다. 다음 번에 업그레이드하세요.)

상하이 업그레이드 진행

2023년 1월 섀도우 포크가 진행될 예정이며, 3월에는 상하이 업그레이드 하드포크가 진행될 예정입니다. 비콘 체인에 약속된 ETH의 출금 기능 외에도 비콘 체인의 출금 기능도 EOF 및 기타 작은 업그레이드를 구현할 것으로 예상됩니다. 총 9개의 EIP를 달성합니다. 한편, 2023년 1월 5일 열리는 다음 올코어 개발자 회의에서는 출금 기능 진행에 영향을 미치지 않도록 EOP 구현을 2023년 가을로 연기할지 여부가 결정될 예정이다. 동시에 많은 기대를 모았던 EIP-4844가 2023년 가을에 구현될 예정입니다.

참고: 간단히 말해서 섀도우 포크는 메인넷 데이터를 사용하여 작은 범위의 노드 내에서 테스트하는 스트레스 테스트 방법입니다. 업데이트된 구성으로 소수의 노드를 실행함으로써 이더리움 네트워크는 섀도우 포크 네트워크를 얻기 위해 포크됩니다. 이러한 방식으로 섀도우 포크는 원본에 있는 대부분의 노드의 상태에 영향을 주지 않고 원래 네트워크의 상태와 기록을 상속할 수 있습니다. 네트워크. 포크 이전의 네트워크 작동에는 영향을 미치지 않습니다. 이것의 장점은 메인 네트워크의 데이터 볼륨과 트랜잭션이 가장 복잡하여 노드가 실제 상황을 시뮬레이션하는 데 도움이 될 수 있다는 것입니다.

업그레이드 세부정보

돈을 인출하다

포함될 수 있는 개념

먼저 인출에 대한 이해가 필요합니다. Validator가 무엇인지, ETH 2.0이 무엇인지, The Merge에서 어떤 일이 일어나는지 등에 대한 막연한 개념이 필요합니다. 그것.

잘 모르겠다면 이더리움 2.0 지식 베이스를 읽어보거나 현재 상황을 간단하게 이해할 수 있습니다. 이더리움은 이제 합의 계층과 실행 계층으로 나누어집니다. 합의 계층에는 호출되는 여러 작업자가 있습니다. 검증인은 합의 계층에 있으며(비콘 체인) 이 보증을 통해 이더리움에 기여하고 일부 수입을 교환하여 서로를 감독할 수 있습니다. 및 수입., 검증인은 꺼낼 수 없습니다.

검증인의 책임

검증인은 세 가지 주요 책임을 가집니다.

(1) Propose 블록은 이전 채굴자의 책임을 상속하지만 현재 대부분의 Validator는 Proposer 빌더 분리를 간접적으로 구현하기 위해 mev-boost를 설치하기로 선택했습니다. MEV 및 MEV-boost에 대해 더 자세히 알고 싶다면 A&T View를 읽어보세요. 이더리움 스테이킹 인출 가능 가치에 대한 투자 기회

(2) 서명 증명은 다른 검증자가 제안한 블록의 유효성을 확인하기 위해 검증자가 투표하는 것을 말하며 각 에포크마다 한 번씩 수행되며 책임 1을 보완합니다.

(3) 슬래시 가능한 위반에 대해 다른 유효성 검사기를 모니터링합니다. 일반적인 위반에는 증명 위반이 포함됩니다.

슬롯과 에포크

Slot과 Epoch는 시간 단위로 이해될 수 있으며, 이는 시간 간격, 창 기간을 나타냅니다. 이들은 기간의 길이인 12s/슬롯, 32 Slots = 1 Epoch, 6.4mins/Epoch에 해당하므로 하나입니다. 12초 슬롯마다, 6.4분마다 한 에포크가 있으며, 매일 225개의 에포크가 있습니다.

Slot과 Epoch는 인출을 이해하는 데 중요한 역할을 합니다. 왜냐하면 Validators는 Slot 또는 Epoch 단위로 작동하고 이러한 이유로 인출도 Slot 또는 Epoch 단위로 계산되기 때문입니다.

사진 출처: https://eth2book.info/altair/part2/building_blocks/aggregator

일반적으로 각 슬롯에는 무작위로 선택된 유효성 검사기가 있습니다. 이 유효성 검사기는 블록을 제안할 수 있습니다(슬롯에는 유효한 블록이 하나만 있지만 각 슬롯에 반드시 블록이 있을 필요는 없습니다. 예를 들어 이 슬롯에서 선택된 유효성 검사기는 블록을 오프라인으로 제안합니다). . 동시에 모든 검증인은 여러 위원회(위원회)로 나누어지며, 각 위원회에는 최소 128명에서 최대 2048명의 검증인이 참여하여 각 슬롯을 인증하는 역할을 독립적으로 담당하며 일부 검증인은 무작위로 선택됩니다. 각 위원회의 Aggregator 수는 현재 16명입니다. Aggregator는 검증자의 증명 표를 집계하여 다음 블록 제안자에게 전달하는 역할을 담당합니다. 각 에포크 후에 위원회는 해체되고 재조직됩니다.

검증인 상태

Validator에는 여러 가지 공통 상태가 있습니다. 상태에 따라 다양한 Validator 출금 조건이 충족됩니다. 따라서 출금이 어떻게 발생하는지 올바르게 이해하려면 Validator의 주요 상태를 알아야 합니다. 분명히 모든 검증인이 활성 상태인 것은 아니지만 활성 및 철회 가능 상태의 검증인만이 출금 조건을 충족합니다.

1. 입금

먼저, Validator가 되기 위해 사용된 32 ETH를 먼저 메인 네트워크의 Deposit Contract에 입금해야 하며, 이 상태는 각 Validator가 성공적으로 생성된 후 약 7시간 동안 Pending 상태를 유지해야 합니다. (색인), 이 숫자는 단조롭게 증가합니다. 즉, 나중에 유효성 검사기가 될수록 색인이 더 커집니다.

2.보류 중

검증인이 입금을 완료한 후에는 공식 검증인 예비군이 되며, 다른 활성(활성) 상태 검증인의 투표가 보류 상태로 들어갈 때까지 기다려야 합니다. 이러한 종류의 투표는 4시간마다 발생합니다.

Pending 상태에 진입한 후 검증인은 완전히 활성화되기를 기다리는 대기열에 들어갑니다. 각 Epoch에 대해 활성화할 수 있는 검증인의 수는 "이탈 제한 계수(CHURN_LIMIT_QUOTIENT)"에 의해 제한됩니다.

최대(MIN_PER_EPOCH_CHURN_LIMIT, n // CHURN_LIMIT_QUOTIENT)

MIN_PER_EPOCH_CHURN_LIMIT = 4인 경우 n은 활성 유효성 검사기 수, CHURN_LIMIT_QUOTIENT = 65536입니다.

따라서 2022년 12월 29일 데이터를 예로 들면, 네트워크에는 현재 492,975개의 활성 검증자가 있으므로 Epoch당 활성화할 수 있는 새로운 검증자의 수는 현재 7개입니다. 하루에 225개의 Epoch를 기준으로 계산하면, 하루에 활성화할 수 있는 새로운 검증인의 수는 1575명입니다.

3. 활동적

활성 상태의 검증인은 검증인의 잔액이 16 ETH 미만으로 떨어지거나 자발적으로 종료되거나 삭감될 때까지 증명 및 제안 블록(작업 시작)에 참여할 수 있습니다.

검증인이 제안된 블록을 놓치거나 증명에 참여하는 경우 이 상태를 오프라인(결근)이라고 합니다. 최소 2개의 에포크가 증명에 참여하지 않으면 검증인은 일반적으로 온라인 상태여야 합니다. 적어도 50%는 긍정적인 수익을 얻기 위해서만. 그러나 오프라인 검증인은 여전히 활성 상태를 유지합니다. 슬래시된 경우(규율을 위반한 것으로 밝혀진 경우) 네트워크에서 강제로 종료되고 잔액의 최소 1/32이 압수됩니다.

4. 청산 및 출금 가능

비활성 검증인은 강제로 네트워크를 떠나고(Exit) 다시 합류할 수 없습니다. 반면, 검증인이 네트워크를 떠나는 속도도 엄격하게 제한됩니다. 실제로 보류 섹션에 언급된 검증인 활성화 속도 제한은 실제로 전체 네트워크에서 검증인의 이탈에 대한 제한입니다. 이 제한의 목적은 검증인 수가 너무 빨리 변경되어 네트워크가 불안정해지는 것을 방지하는 것입니다 . 동시에, 네트워크를 종료한 검증인(Exit 상태)이 자금을 인출하는 데(Exit -> Withdrawable) 약 27시간이 소요됩니다. 동시에 강제 종료된 검증인의 경우에는 약 27시간이 소요됩니다. 위반에 대한 페널티로 인해 출금 가능 상태가 되기까지 추가로 36일이 소요됩니다. 현재 비콘체인에는 867개의 검증자가 적극적으로 퇴장하고 있으며, 223개의 검증자가 슬래시되어 퇴출된 상태입니다. 네트워크를 적극적으로 종료하려면 Prysm 종료 |

검증자 수, 이더리움 발행 및 APR의 관계

자세한 내용은 이더리움 업그레이드 에서 확인할 수 있습니다.

N은 검증자 수, 225는 매일 실행할 수 있는 Epoch 수입니다.

원천

APR과 N의 성장 사이에는 음의 상관관계가 있습니다. 이 설계에는 몇 가지 이유가 있습니다. 첫 번째는 APR이 N과 관련된 기능임을 보장하는 것입니다. 이는 비용이 분명히 N의 증가보다 높을 때 합리적인 검증자가 결정적으로 종료하는 것을 방지할 수 있습니다. 동시에 보안을 위해 초과 지불을 피할 수 있습니다.

반면에 APR과 N 사이에 음의 상관관계가 있으면 검증인이 다른 사람의 작업을 검토하고 부적절한 행동을 하는 검증인을 네트워크에서 추방하는 방법을 찾도록 장려할 것입니다.

원천

0x01 자격 증명 및 0x00 자격 증명

0x01과 0x00은 모두 입금 시 검증인이 받은 증거입니다. 0x01 자격 증명을 보유한 검증인만이 돈을 성공적으로 인출할 수 있다는 점만 알면 됩니다. 왜냐하면 0x01에는 검증인 소득의 목표 주소가 포함되어 있기 때문입니다. 0x00 Credential을 보유하고 있으므로 상하이에서 업그레이드한 후 0x01 Credential로 업그레이드해야 합니다. 0x01 Credential로 업그레이드하는 방법을 알고 싶다면 [Tim의 Twitter](https: //twitter.com/TimBeiko/status/1600939567523037184)를 참조하세요. ). 이러한 변화는 인출 계획의 변경으로 인한 것입니다.

현재 비콘 체인에는 몇 개의 검증기와 ETH가 있습니까?

Beaconcha.in의 데이터에 따르면 12월 29일 현재 비콘 체인에 실제로 약속된 ETH는 15,775,062 ETH( 이 데이터는 스테이크 수익 및 페널티를 계산하는 데 사용된 ETH의 양을 계산함 )였으며 활성 검증인 수는 492,975명입니다. 총 494,096명의 검증인이 있습니다. 현재 검증인당 약속된 평균 ETH는 33.93 ETH입니다(즉, 비콘 체인의 총 ETH 수는 16,764,677 ETH입니다). 현재 스테이킹 수익률이 가장 높은 검증인 주소는 36.9690 ETH이며, 스테이킹 시간은 700일 이상이다.

출금은 어떻게 구현되나요?

출금은 실행 계층과 합의 계층의 공동 업그레이드를 통해 구현됩니다. 실행 계층은 주로 EIP-4895를 도입하여 철회 프로세스에서 합의 계층을 지원합니다. 구체적으로 EIP-4895는 출금을 완료하기 위해 "Pull" 아이디어가 아닌 "Push" 아이디어 구조를 기반으로 합니다 . 즉, 사용자가 출금 요청을 적극적으로 시작할 필요는 없지만 , 인출을 기반으로 해당 응답을 생성합니다. 비콘 체인의 검증인 상태. "Receipt", 이 영수증에는 출금을 완료하는 데 필요한 세부 정보가 포함됩니다. 영수증은 각 블록이 패키징될 때 실행됩니다. 정해진 시간 내에 실행 가능한 출금 요청은 엄격하게 제한됩니다.

참고: 1) 이러한 출금 요청은 "시스템 수준" 작업 유형이며 독립적으로 수행되지 않거나 사용자의 일반 거래 멤풀에 들어가지 않습니다. 즉, 출금은 거래가 완료된 후에 수행됩니다. 블록 공간을 놓고 경쟁하기 위해 사용자와 상호 작용이 없습니다. 실행 클라이언트가 Engine API를 통해 동기화하는 경우에만 실행 블록에 들어갑니다. 따라서 인출은 이더리움의 가스를 증가시키거나 이더리움을 더 혼잡하게 만들지 않습니다.

2) 페이로드는 컨트랙트 사용자에게 호출하려는 함수와 이 함수에서 사용하는 매개변수의 값을 알려주는 데 사용됩니다. 시스템 수준 작업은 출금을 새로운 거래 유형으로 정의하는 대신 출금 동작을 사용자의 일반적인 거래 동작과 구별하기 위해 새로운 페이로드 객체 '철회'를 정의한다는 의미입니다. 이 방법은 더 복잡하지만 테스트하기가 더 쉽습니다. 구현하는 것이 더 안전합니다. 페이로드에 대해 자세히 알아보기

이더리움 거래 영수증에서 페이로드 필드의 용도는 무엇인가요?
이더리움 거래 내 데이터 페이로드 이해
3) 카펠라 업그레이드 내용
Capella는 다음을 포함하여 검증인 출금과 관련된 다양한 기능을 포함하는 합의 계층 업그레이드입니다.

'철회 가능한' 검증인의 자동 인출.
0x01 출금 자격 증명과 'MAX_EFFECTIVE_BALANCE'(32ETH)를 초과하는 잔액을 가진 검증인을 대상으로 부분 출금이 진행됩니다.
검증인의 출금을 활성화하기 위해 `BLS_WITHDRAWAL_PREFIX`(0x00)에서 `ETH1_ADDRESS_WITHDRAWAL_PREFIX`(0x01) 버전의 출금 자격 증명으로 변경하는 작업입니다.

탈퇴 조건

인출에는 두 가지 유형이 있습니다. "부분 출금"과 "전체 출금"은 조건이 다릅니다. 출금은 전자동으로 이루어지기 때문에 부분 출금과 전체 출금의 우선 순위에는 차이가 없습니다. 즉, 필요한 조건을 충족하고 기다리면 됩니다.

  • 필수 조건: 유효성 검사기에는 0x01 자격 증명이 있습니다.
  • 부분 출금 조건: 검증인이 활성화되어 있고 검증인의 잔액이 32ETH보다 큽니다.
  • 모든 출금 조건: 검증인은 출금 가능합니다(이는 일반적으로 검증인이 네트워크를 종료했음을 의미합니다).

인출 방법

https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/beacon-chain.md#has_eth1_withdrawal_credential을 직접 볼 수 있습니다.

검증인이 블록을 제안하면 검증인의 인덱스에 따라 모든 검증인을 선형적으로 스캔하여 출금 조건을 충족하는 처음 16개의 검증인이 세트를 형성하고 출금 실행을 기다리는 ExecutionPayload에 포함됩니다.

즉, 각 에포크에는 돈을 인출할 수 있는 검증인이 512명(1 에포크에는 32개의 슬롯이 있고, 1개의 슬롯은 1블록이기 때문)이 있으며, 하루에 115,200명의 검증인이 돈을 인출할 수 있게 됩니다(1 에포크에는 6.4분이 소요되며, 하루에 약 225개의 검증자가 있습니다.), 5일 이내에 모든 검증자가 통과됩니다.

이상적으로, 이러한 115,200개의 인출이 모두 부분 인출인 경우 지수에 따라 낮은 것부터 높은 것까지, 지수에 있는 처음 115,200명의 검증인의 인출 잔액은 3 - 4 ETH입니다(beaconcha 데이터에 따르면 약속된 가장 빠른 검증인의 잔액은 ETH입니다). 는 약 36.3 ETH이며, 115,200번째 검증인의 잔액은 약 35 ETH입니다.) 중간 숫자인 3.5 ETH를 기준으로 계산하면 첫날 출금 기능으로 인해 잠금 해제된 ETH는 약 403,200 ETH(115200 * 3.5)입니다. 동일한 계산 방법을 사용하면 업그레이드 둘째 날에는 약 2.5 * 115,200 = 288,000 ETH가 잠금 해제되고, 셋째 날에는 1.5 * 115200 = 172,800 ETH가 잠금 해제됩니다. 4일차에는 약 0.5*115200 = 57,600 ETH가 잠금 해제됩니다. 5일차부터 대부분의 검증인은 이미 코인을 인출했기 때문에 이전처럼 매도 압력이 크지 않을 것입니다.

참고: ETH 스테이킹은 2020년 12월에 시작되었습니다. 당시 ETH의 가격은 $1,000 정도였습니다. 따라서 이후 서약에 참여한 ETH의 대부분은 현재 가격에 비해 손실을 입었습니다.

이미지 출처: Cryptorank

그러나 실제로 인출이 예상만큼 원활하게 진행되지 않을 수도 있으며, 실제 인출 금액이 이상적인 가치보다 높거나 낮아지는 예상치 못한 상황이 항상 있을 수 있습니다.

  • 잠금 해제 금액이 이상적인 값보다 낮은 상황
  • 모든 검증인이 0x01 자격 증명인 것은 아니며 모든 활성 검증인이 32 ETH를 갖는 것은 아닙니다. 따라서 (다양한 이유로) 철회 조건을 충족하지 않는 일부 유효성 검사기가 있습니다. 이러한 규칙을 충족하지 않는 유효성 검사기는 통과 중에 통과됩니다. ) 상한은 `MAX_VALIDATORS_PER_WITHDRAWALS_SWEEP` = 16384(2**14)입니다.
  • 잠금 해제 금액을 이상적인 것보다 높게 설정하세요.
  • 유효성 검사기가 모든 출금을 선택할 수 있는 옵션이 있습니다. 이론적으로, 처음 115,200명의 검증인이 모두 출금하기로 선택한 경우 첫날 잠금 해제된 금액은 3,686,400 ETH가 됩니다. 그러나 모든 출금의 전제조건은 네트워크를 탈퇴하는 것이며, 매일 네트워크를 탈퇴할 수 있는 검증인의 수는 현재 네트워크를 탈퇴할 수 있는 검증인 수의 상한선에 의해 엄격하게 제한됩니다. 매일은 1,575입니다.

인출로 인해 발생할 수 있는 영향

참고: 다음은 이 작업을 수행할 때 떠오르는 몇 가지 질문과 의견입니다. 이는 투자 조언이 아닙니다.

Q1: 잠금 해제된 ETH는 시장에서 대량으로 판매되나요?

업그레이드 후 처음 며칠 동안 많은 양의 ETH가 잠금 해제되었지만 잠금 해제가 판매된다는 의미는 아닙니다. ETH를 잠금 해제한 이 스테이커 그룹의 비용은 현재 ETH 가격을 기준으로 낮지 않습니다. 잠금 해제가 언제 발생할지 모르고 ETH에 가입한 사용자로서 대부분이 ETH를 매수한 것으로 생각됩니다(증거 없음). 순전히 추측입니다.) 이익이 충분하지 않으면 개인적으로 ETH 판매를 선택하지 않고 다시 약속을 선택할 수도 있다고 생각합니다. 동시에, 출금이 가능하기 때문에 ETH를 스테이킹하면 잠금 해제 시간과 잠금 해제 기간이 더 명확해지며, 이는 위험이 낮아지고 더 많은 사용자가 스테이킹에 참여하도록 유도할 수 있다고 믿어집니다.

Q2: 유동성 스테이킹 서비스에 어떤 영향을 미칠까요?

리도(Lido)를 예로 들어 추측해 보겠습니다.

출금 프로세스에 따르면 대부분의 출금은 "부분 출금"을 통해 이루어집니다. 즉, 유동성 스테이킹 서비스 제공업체의 경우 실제로 잠금 해제될 수 있는 유일한 ETH는 플랫폼에서 실행되는 유효성 검사기의 이익입니다. 분명히 다양한 관점에서 볼 때 Validator를 종료하도록 허용하는 플랫폼은 그렇게 할 인센티브가 없습니다.

이는 극단적인 상황으로 이어질 것입니다. 즉, unstake 직후 stETH를 1:1 비율로 ETH로 변환할 수 있다면, 다수의 stETH 보유자가 교환을 신청하면 총 금액이 Lido가 ETH를 통해 얻은 금액을 초과하게 됩니다. ETH 총액에 도달하면 stETH에 상환할 ETH가 없는 상황이 발생하게 됩니다(실제로는 여전히 잠겨 있기 때문입니다). 따라서 잠금 해제 후에도 stETH와 ETH의 1:1 교환이 이루어집니다. 플랫폼이 다음을 수행할 수 있도록 완충 기간이 필요합니다. 유효성 검사기의 서약을 해제하는 데는 시간이 걸립니다. 바로 이러한 시간 차이 때문에 stETH가 대표하는 서약 파생 상품이 여전히 1보다 약간 낮은 환율로 ETH와 풀링됩니다. :1 상하이에서 업그레이드 후.

인출 연기의 한 가지 장점은 실행으로 인한 패닉과 위험을 줄이는 것입니다. 또한, 또 다른 잠재적인 이점이 있습니다. 즉, Lido가 직면한 어려움은 모든 유동성 스테이킹 서비스 제공업체에서 직면하게 되므로 ETH 출금 지연 서약은 유동성 스테이킹 서비스 제공업체의 공통 모델이 될 가능성이 높습니다. 이것이 왜 좋은 일입니까? stETH의 해자 중 하나가 좋은 유동성과 결합성이기 때문에 담보가 해제된 후에는 모든 담보 파생상품을 ETH로 1:1로 교환할 수 있기 때문에 stETH의 유동성 이점이 사라질 우려가 있지만 메커니즘이 인출 지연이 존재하며 stETH는 여전히 유동성 이점을 유지합니다.

인출에 대해 더 자세히 알고 싶다면 다음 정보를 읽어보세요.

  • https://www.youtube.com/watch?v=CcL9RJBljUs
  • https://notes.ethereum.org/@ralexstokes/validator-withdrawals-meta-spec

EOF

포함될 수 있는 개념

EVM

이더리움과 비트코인의 가장 중요한 차이점 중 하나는 스마트 계약의 추가이며, EVM은 스마트 계약을 실행하는 운영 체제로 이해될 수 있습니다. 추천 자료: https://noxx.substack.com/p/evm-deep-dives-the-path-to-shadowy?s=r

바이트 코드

일반적으로 개발자는 Solidity라는 고급 프로그래밍 언어를 사용하여 스마트 계약을 작성할 수 있습니다. 그러나 Solidity로 작성된 스마트 계약은 사람이 읽을 수 있지만 컴퓨터는 읽을 수 없으므로 EVM에서 EVM 바이트 코드로 해석한 후 실행해야 합니다. 인간이 읽을 수 있는 고급 언어(Solidity)를 컴퓨터만 읽을 수 있는 언어(바이트코드)로 바꾸는 것입니다.

아래 그림에서 위의 설명되지 않은 16진수 코드 문자열은 바이트코드입니다. 0x로 시작하면 EVM이 다음 시리즈를 16진수로 읽습니다. 컴파일 전 견고성

이미지 출처: Etherscan 방금 거래 스크린샷을 찾았습니다.

연산코드 연산코드

Opcode(작동 코드), 간단히 말하면 바이트코드는 일반적으로 일련의 Opcode와 해당 입력 값입니다. opcode는 상대적으로 읽기 쉬운 EVM의 작업 명령어를 나타냅니다. 이러한 명령어는 0x01에 해당하는 'ADD'와 같이 정확히 일치하는 16진수 코드를 갖습니다. 각 opcode에는 가스가 필요합니다.

https://ethervm.io/의 사진

스택 머신

EVM은 LIFO (Last in, First Out)를 사용하여 읽는 스택 머신입니다. 간단히 이해하면 EVM opcode의 입력 값이 스택에 들어가고 스택에 따라 읽혀진다는 것입니다. 이더리움에는 이론적으로 최대 256개의 opcode가 있습니다. 각 opcode는 스택 상단에 요소를 팝하고 결과를 스택에 푸시합니다. 자세한 내용은 스택에 대한 심층 요약을 참조하세요.

프로세스 흐름 작업

프로세스 흐름 작업은 주로 다음 opcode를 참조합니다.

이미지 출처: https://ethereum.github.io/execution-specs/autoapi/ethereum/dao_fork/vm/instructions/control_flow/index.html

  • 중지: EVM 코드 실행을 중지합니다.
  • PC: 프로그램 카운터, 현재 읽은 바이트코드의 필드를 지정하는 데 사용됩니다. 바이트코드의 다음 명령어가 실행될 위치를 확인한 후 JUMP를 통해 실행해야 하는 함수로 점프합니다.
  • JUMP: 다음에 실행할 명령을 변경합니다.
  • JUMPI: 조건부 점프
  • JUMPDEST : JUMP의 목적지
  • offset: 각 명령어의 위치를 바이트 단위로 나타내는 데 사용되는 오프셋입니다. 비트, 바이트, 워드는 컴퓨터 데이터 저장 단위입니다. 비트는 가장 작은 저장 단위 로, 각 비트는 1비트의 이진 코드를 저장하고, 1바이트는 8비트로 구성됩니다. 워드는 일반적으로 16, 32 또는 64비트로 구성됩니다.
  • 비트는 가장 기본적인 개념입니다. 컴퓨터에서는 논리 0과 논리 1만 존재하므로 많은 사물, 동작, 숫자는 1001 0000 1101 등과 같은 이진 코드의 문자열로 표현되어야 합니다. 각 논리 0 또는 1은 비트입니다.
  • 1바이트는 8비트로 구성된 단위입니다. 즉, 8비트가 1바이트를 구성합니다. 바이트는 무엇에 사용되나요? 컴퓨터 과학에서는 ASCII 문자를 나타내기 위해 문자와 일부 기호를 기록하는 데 바이트가 사용됩니다. 예를 들어 문자 A는 "0100 0001"로 표시됩니다.
  • 워드(Word)는 컴퓨터 처리 명령이나 데이터의 이진수를 나타내며, 데이터 저장 및 처리를 위한 컴퓨터 연산의 단위이다. 단어 크기는 32비트 컴퓨터와 64비트 컴퓨터에서 서로 다른 경향이 있습니다.

스마트 계약 배포

스마트 계약을 배포하려면 수신자를 지정하지 않고 컴파일된 스마트 계약 코드가 포함된 이더리움 트랜잭션을 보내면 됩니다. 현재 이더리움은 트랜잭션에 컴파일된 스마트 컨트랙트를 포함하고 있기 때문에 소스코드가 없으며, 이더리움은 스마트 컨트랙트 실행 시 바이트코드에 직면하기 때문에 실행 전 스마트 컨트랙트의 정확성을 사전에 검증하기가 어렵습니다.

EOF 란 무엇입니까?

EOF는 새로운 계약 표준과 일부 새로운 opcode를 도입한 EVM의 업그레이드입니다. 기존 EVM 바이트코드는 구조화되지 않은 명령어 바이트코드 시퀀스입니다. EOF는 구조화된 바이트코드를 구현하는 컨테이너 개념을 도입합니다. 컨테이너는 헤더와 바이트코드를 구성하는 여러 섹션으로 구성됩니다. 업그레이드 후 EVM은 버전 제어를 수행하고 동시에 여러 계약 규칙 세트를 실행할 수 있습니다. 이번 EOF 업그레이드는 EIP-3540, EIP-3670, EIP-4200, EIP-4750, EIP-5450 등 5개의 EIP로 구현됩니다. EOF는 대규모 업그레이드이기 때문에 1월에 원활한 출금이 가능하도록 하기 위해 지연될 수 있습니다.

자세한 내용은 EVM 개체 형식(EOF)을 참조하세요.

EOF의 의미

간단히 말해서 EOF는 새로운 계약 규칙 세트입니다. 현재 실행 중인 EVM은 해석 및 검증 규칙 세트만 동시에 실행할 수 있습니다. 이 규칙 세트는 레거시 계약이라고 하는 모든 기존 계약에 적용됩니다. EOF는 새로운 계약 규칙 세트를 도입하고 그에 따라 EVM 해석기를 업그레이드합니다. 업그레이드 후 EVM은 EOF 계약 한 세트와 레거시 계약 한 세트, 두 세트의 계약 규칙을 병렬로 실행할 수 있습니다.

EOF를 사용하면 EVM은 반복 시 향후 호환성에 대한 요구로 인해 더 이상 제한되지 않습니다. 업그레이드 난이도가 낮으면 향후 Ethereum EVM이 더 자주 업그레이드될 수 있습니다.

빈번한 EVM 반복으로 인해 zkEVM과 같은 EVM 호환 가상 머신에 대한 요구 사항이 높아질 수 있습니다. 버전을 유지하려면 EOF 업데이트를 자체 VM으로 자동 변환하는 기능을 갖춘 다른 EVM 호환 VM이 필요할 수 있습니다. .

각 EIP는 정확히 어떤 역할을 합니까?

EIP-3540: EVM 개체 형식(EOF) v1

이전 체인에 배포된 EVM 바이트코드는 사전 정의된 균일한 구조를 갖지 않습니다. 이는 클라이언트에서 실행될 때까지 코드가 검증되지 않으며 이는 간접적인 비용일 뿐만 아니라 개발자가 새로운 기능을 도입하는 데 방해가 됩니다. 오래된 기능. 본 EIP는 EVM으로 확장 및 버전화할 수 있는 컨테이너를 도입하고, EOF 컨트랙트의 형식을 선언합니다(아래 참조). 이를 기반으로 EOF 컨트랙트 배포 시 코드 검증, 즉 생성 시간 검증이 가능합니다. 이는 EOF 형식을 준수하지 않는 계약이 배포되는 것을 방지할 수 있음을 의미합니다. 이 변경은 EOF 버전 제어를 구현하고 향후 기존 EVM 지침을 비활성화하거나 대규모 기능(예: 계정 추상화)을 도입하는 데 도움이 됩니다.

이 EIP가 제공하는 첫 번째 실질적인 기능은 데이터와 코드를 구별하는 것입니다. 이러한 구별은 온체인 코드 검증자에게 매우 유용하여 가스 소비를 절약합니다.

EIP-3670: EOF - 코드 검증

EIP-3670은 EIP-3540을 기반으로 하며 EOF 계약의 코드가 형식을 준수하고 유효한지 확인하는 것을 목표로 하며 형식을 준수하지 않는 계약은 배포가 방지되고 레거시 바이트코드에 영향을 미치지 않습니다.

EIP-4200: EOF - 정적 상대 점프

EIP-4200은 대상을 부호 있는 즉시 값으로 인코딩하는 RJUMP, RJUMPI 및 RJUMPV와 같은 최초의 EOF 관련 opcode를 도입합니다. 컴파일러는 이러한 새로운 JUMP 연산 코드를 사용하여 기존 JUMP 및 JUMPI 연산 코드로 점프 테스트 분석을 수행하는 데 필요한 런타임을 제거하므로 JUMP 배포 및 실행에 드는 가스 비용을 최적화할 수 있습니다. 이 EIP는 동적 점프를 보완합니다.

기존 JUMP 작업과 비교할 때 RJUMP와 같은 작업은 특정 오프셋 위치를 지정하지 않고 상대 오프셋 위치(동적 점프 -> 정적 점프)를 지정한다는 차이점이 있습니다. 왜냐하면 여러 번 정적 점프로 충분하기 때문입니다.

EIP-4750: EOF - 기능

EIP-4750은 4200의 기능을 한 단계 더 발전시킵니다. 두 개의 새로운 opcode 'CALLF' 및 'RETF'를 도입하여 RJUMP, RJUMPI 및 RJUMPV로 대체할 수 없는 상황에 대한 대안을 구현하여 EOF 계약의 구현을 실현합니다. JUMPDEST가 더 이상 필요하지 않으므로 동적 점프가 비활성화됩니다.

EIP-5450: EOF - 스택 검증

EIP-5450은 이번에는 스택 주변에서 EOF 계약에 또 다른 유효성 검사를 추가합니다. 이 EIP는 EOF 계약 배포로 인해 스택 언더플로우/오버플로우(스택 언더플로우/오버플로우)가 발생하는 것을 방지합니다. 이러한 방식으로 클라이언트는 EOF 계약 실행 중에 수행하는 유효성 검사 횟수를 줄일 수 있습니다.

배포 시 이더리움 컨트랙트가 확인되지 않는다는 배경은 여전히 존재합니다. 일련의 확인은 실행 시에만 수행되며, 스택이 오버플로되었는지(상한은 1024), 가스가 충분한지 등입니다. EOF의 주요 개선 사항은 실행 중에 발생하는 이러한 검사를 가능한 한 적게 만들고 계약이 배포될 때 더 많은 검사가 발생하도록 하는 것입니다.

기타 사소한 업그레이드

EIP-3651: 따뜻한 COINBASE

EIP-3651을 이해하려면 먼저 EIP-2929를 이해해야 합니다. EIP-3651은 실제로 EIP-2929로 인한 문제를 해결하기 때문입니다.

그렇다면 EIP-2929는 무엇일까요?

EIP-2929의 전체 이름은 State Assess Lists입니다. 간단히 말해서 EIP-2929는 일부 트랜잭션이 처음 실행될 때 더 많은 비용을 발생시킵니다(가스 비용은 액세스 스토리지 유형에 따라 다름). 트랜잭션에는 슬레이브가 필요합니다. Cold to Warm 프로세스가 처음으로 트리거된 후 주소는 Warm 상태로 변경됩니다. Warm 상태는 동일한 주소에 대한 후속 방문이 더 저렴하다는 것을 의미하므로 동일한 Opcode를 실행해야 합니다. 동일한 거래 내에서 여러 번 수행하면 보다 저렴해지고 일부 계정은 기본적으로 웜 상태입니다. EIP-2929 당시에는 송신 주소와 수신 주소가 기본적으로 Warm 주소였습니다. 실제로 EIP-2929는 평균 가스 소비량을 줄이지 않았고 심지어 약간 증가했습니다(0.3%~0.4% 증가). EIP-2929의 주요 목적은 DoS 공격 비용을 높이는 것이기 때문에 이에 대한 조치가 필요합니다. 상태 액세스 opcode의 가스 소비를 늘리는 동시에 사용자가 실제로 거래를 시작하는 데 사용하는 가스의 균형을 맞추기 위해 자주 사용하는 일부 계정이 기본적으로 따뜻해집니다.

EIP-3651은 기본적으로 `COINBASE` 주소, 즉 feeRecipient 주소라고도 불리는 `COINBASE` 주소를 워밍업합니다. 이번 변경은 주로 'COINBASE'가 초기에 "Cold" 상태가 되어 COINBASE 주소와 관련된 거래 수수료가 더 비싸지게 되는 EIP-2929의 문제를 해결하기 위한 것입니다. 구체적인 수정 방법은 EIP-2929에서 제안하는 Access List Framework에 COINBASE의 주소를 추가하여 'COINBASE'의 주소도 기본적으로 Warm 상태가 되도록 하여 COINBASE 주소와의 상호 작용이 더 이상 소모되지 않도록 하는 것입니다. 액세스 목록의 다른 주소와 상호 작용하는 것보다 더 많은 수수료가 발생합니다.

EIP-3651의 영향은 MEV 추출기, 블록 빌더 및 검증인이 COINBASE 주소와 관련된 거래에서 비용을 절감할 것이라는 점입니다. 왜냐하면 EIP- 구현 후 William Morriss에 따르면 COINBASE는 기존 결제에서 수많은 블록 빌더에 의해 사용되기 때문입니다. 3651, COINBASE 주소와 상호 작용하는 데 드는 대략적인 비용은 약 2600가스의 비용이 드는 계정을 포함하지만 웜 후에는 100에 불과합니다.

참고: COINBASE 주소는 무엇인가요?

여기서 COINBASE는 블록 빌더가 네트워크에서 새로운 토큰을 수락하는 데 사용하는 소프트웨어를 의미합니다. 블록 빌더는 일반적으로 mempool의 트랜잭션을 블록으로 패키징하고 이를 정렬을 위해 Validator로 보내고 그로부터 수익을 수집합니다. 각 거래마다 COINBASE 소프트웨어와의 여러 상호 작용이 필요하며 현재 COINBASE 주소를 워밍업해야 하기 때문에 첫 번째 상호 작용은 일반적으로 더 비쌉니다. 이후 상호 작용 횟수가 증가함에 따라 상호 작용 비용은 천천히 감소하며 EIP -3651 COINBASE가 처음부터 워밍업 상태가 되도록 하여 COINBASE로 자금을 이체하는 데 드는 비용을 절감합니다.

조건부 지불: EIP-1559는 조건부 지불을 가능하게 합니다. 즉, MaxPriorityFeePerGas를 0으로 설정하여 거래가 실패할 때 가스 요금이 부과되지 않는 방법을 사용합니다. 동시에 이러한 실패한 거래는 검열 저항력도 뛰어납니다. 왜냐하면 거래가 실패했기 때문에 블록 빌더가 가스를 청구하지 않았고 해당 정보가 저장되지 않았기 때문입니다. 단, 조건부 결제를 이용하려면 COINBASE 계정에 접속해야 합니다.

EIP-3855: PUSH0 명령

0 값을 스택에 푸시하는 새로운 opcode를 도입합니다. PUSH 0은 EVM에서 일반적인 상황입니다(PUSH* 명령의 11.5%가 0 값을 스택에 PUSH하는 데 사용됨). 이 EIP는 이를 달성하기 위한 보다 효율적이고 저렴한 방법을 제공합니다(현재 `PUSH1 0` 등을 통해). , 0 값을 Stack에 넣어야 하는 모든 상황에 대해 통일되고 표준적인 사용법을 제공합니다.

EIP-3860: 초기화 코드 제한 및 측정

이 EIP는 ' initcode '에 대한 최대 크기를 추가하고 길이에 따른 가스 측정을 도입합니다. 크기 제한은 EVM에 불변성을 추가하여 변경 사항을 더 쉽게 추론하고 제안할 수 있도록 합니다.

'initcode'에 대한 2가스/32바이트 비용은 이전에는 가스 일정에서 고려되지 않았던 실행 전에 클라이언트가 수행해야 하는 가장 빠른 분석을 설명하기 위해 도입되었습니다.

만약 이 글에 사실적 오류가 있다면 비판과 정정을 해주시면 정말 감사하겠습니다. 순수한 호기심으로.

참조하다

출처
면책조항: 상기 내용은 작자의 개인적인 의견입니다. 따라서 이는 Followin의 입장과 무관하며 Followin과 관련된 어떠한 투자 제안도 구성하지 않습니다.
라이크
즐겨찾기에 추가
코멘트
관련 콘텐츠