이더 리움의 공동 창립자 인 Vitalik Buterin

5 월 3 일 블로그 게시물에서 그는“지금부터 5 년 후에 이더 리움이 비트 코인만큼 단순해질 수있는 방법”을 설명했습니다.

Ethereum co-founder Vitalik Buterin envisions an instance of Ethereum's consensus layer code and a portion of the execution layer code. Together, they span less than 1,000 lines of code, aiming to make it simple enough for a high-school student to comprehend. In contrast, the code for a single large Unix program can exceed 1 million lines.

이더 리움의 공동 창립자 인 Vitalik Buterin은 이더 리움의 합의 계층 코드의 인스턴스와 실행 계층 코드의 일부를 구상합니다. 함께, 그들은 1,000 줄 미만의 코드에 걸쳐 고등학생이 이해하기에 충분히 간단하게 만들기위한 것입니다. 대조적으로, 단일 대형 유닉스 프로그램의 코드는 백만 줄을 초과 할 수 있습니다.

Simplicity is often underestimated in programming. It renders programs more accessible, reduces the cost of creating new infrastructure and maintaining existing infrastructure, and minimizes the risk of bugs.

단순성은 종종 프로그래밍에서 과소 평가됩니다. 프로그램에 더 접근하기 쉽고 새로운 인프라 생성 비용을 줄이고 기존 인프라를 유지하는 비용을 줄이며 버그의 위험을 최소화합니다.

Recently, Ethereum has been making good progress in becoming more robust, thanks to the integration of proof-of-stake (PoS) and Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (zk-SNARK). However, we haven't yet sufficiently prioritized simplicity of design, which has led to additional costs.

최근에, 이더 리움은 스테이크 증명 (PO)의 통합과 제로 지식 간결한 지식 지식 논증 (ZK-SNARK)의 통합 덕분에 더욱 강력 해지면서 좋은 진전을 보이고 있습니다. 그러나 우리는 아직 설계의 단순성을 충분히 우선시하지 않았으므로 추가 비용이 발생했습니다.

Historically, Ethereum has often neglected this aspect (sometimes due to my own decisions), contributing to excessive development expenditure, various security risks, and a relative lack of interoperability with external R&D culture, often in pursuit of benefits that have proven illusory.

역사적으로, 이더 리움은 종종 이러한 측면 (때로는 내 결정으로 인해)을 무시하여 과도한 개발 지출, 다양한 보안 위험 및 외부 R & D 문화와의 상호 운용성 부족, 종종 환상적인 입증 된 혜택을 추구하는 데 기여했습니다.

I believe that over the next 3-5 years, we can and should make significant progress in this direction. We can aim to make Ethereum 5 years from now have consensus-critical code that is close to as simple as Bitcoin, which is something that many people have set as a goal for a long time.

앞으로 3-5 년 동안 우리는이 방향으로 상당한 진전을 이루어야한다고 생각합니다. 우리는 5 년 후에 이더 리움이 비트 코인만큼 단순한 합의 크리티컬 코드를 갖도록 목표로 삼을 수 있습니다. 이것은 많은 사람들이 오랫동안 목표로 설정 한 것입니다.

One of the best things about Bitcoin is how beautifully simple the protocol is. A smart high-school student can read the protocol and understand the main concepts and architecture of the protocol.

비트 코인의 가장 좋은 점 중 하나는 프로토콜이 얼마나 아름답게 단순한 지입니다. 현명한 고등학교 학생은 프로토콜을 읽고 프로토콜의 주요 개념과 아키텍처를 이해할 수 있습니다.

We want to be able to say the same about Ethereum. I think we can get close.

우리는 이더 리움에 대해 똑같이 말할 수 있기를 원합니다. 나는 우리가 가까워 질 수 있다고 생각합니다.

3-slot finality will allow us to eliminate concepts like slots, epochs, and sync committees from the common view. A basic implementation of 3-slot finality can be done in about 200 lines of code, which is simpler than the 1,008 lines of code for the main Harvest aggregator contract.

3 슬롯 최종 성은 공통 견해에서 슬롯, 시대 및 동기화위원회와 같은 개념을 제거 할 수있게 해줍니다. 3 슬롯 결승의 기본 구현은 약 200 줄의 코드에서 수행 할 수 있으며, 이는 주 수확 어 그리 게이터 계약에 대한 1,008 줄의 코드보다 간단합니다.

We will also have fewer active validators at a time, which will make it safer to use simpler implementations of the fork choice rule.

또한 한 번에 활성 유효성 검사기가 적어서 포크 선택 규칙의 더 간단한 구현을 사용하는 것이 더 안전합니다.

We will use STARK-based aggregation protocols for efficient validator slashing aggregation, and anyone can be an aggregator. The complexity of the aggregation cryptography itself is significant, but it is at least highly encapsulated complexity, which has much lower systemic risk toward the protocol.

우리는 효율적인 유효성 검사기 슬래시 집계를 위해 Stark 기반 집계 프로토콜을 사용하고 누구나 집계기가 될 수 있습니다. 집계 암호화 자체의 복잡성은 중요하지만, 적어도 캡슐화 된 복잡성이므로 프로토콜에 대한 체계적인 위험이 훨씬 낮습니다.

This will likely enable a simpler and more robust P2P architecture. We can also rethink and simplify several facets, such as validator entry and exit, inactivity leak, and more, both by reducing line-of-code (LoC) count and by creating more legible guarantees.

이를 통해 더 단순하고 강력한 P2P 아키텍처가 가능할 것입니다. 또한 유효성 검사 (LOC) 카운트를 줄이고보다 읽기 쉬운 보증을 통해 유효성 검사기 입력 및 종료, 비 활동 유출 등과 같은 여러 측면을 다시 생각하고 단순화 할 수 있습니다.

The consensus layer is relatively disconnected from Ethereum Virtual Machine (EVM) executions, providing relatively wide latitude for us to make improvements.

컨센서스 계층은 EVM (Ethereum Virtual Machine) 실행과 비교적 분리되어 우리가 개선 할 수있는 비교적 넓은 위도를 제공합니다.

We can also make the execution layer simpler. Last month, I proposed replacing EVM contract language with RISC-V to boost efficiency by up to 100x.

또한 실행 계층을 더 간단하게 만들 수 있습니다. 지난 달, EVM 계약 언어를 RISC-V로 대체하여 효율성을 최대 100 배까지 대체 할 것을 제안했습니다.

The adoption of RISC-V will also increase simplicity, as the RISC-V spec is absurdly simple compared to the EVM. Of course, we need to ensure that we preserve backwards compatibility for existing applications.

RISC-V의 채택은 RISC-V 사양이 EVM에 비해 터무니없이 단순하기 때문에 단순성을 증가시킬 것입니다. 물론 기존 응용 프로그램에 대한 거꾸로 호환성을 유지해야합니다.

The first thing that is important to understand is: there isn’t one single way to delineate what is the “Ethereum codebase” (even within a single client).

이해해야 할 첫 번째는 다음과 같습니다.“Ethereum Codebase”(단일 클라이언트 내에서도)를 묘사하는 방법은 하나도 없습니다.

The goal is to minimize the green area, by moving code to the yellow area, which indicates code that is very valuable for understanding and interpreting the chain today, or for optimal block building, but is not part of consensus.

목표는 코드를 노란색 영역으로 이동시켜 녹색 영역을 최소화하는 것입니다.이 코드는 오늘날 체인을 이해하고 해석하는 데 매우 유용한 코드를 나타내거나 최적의 블록 빌딩에 동의하지는 않습니다.

We can think of this process as how Apple achieves long-term backwards compatibility through translation layers.

우리는이 과정을 Apple이 번역 계층을 통한 장기적인 거꾸로 호환성을 달성하는 방법으로 생각할 수 있습니다.

Importantly, the orange and yellow areas are encapsulated complexity; anyone looking to understand the protocol can skip them, implementations of Ethereum are free to skip them, and any bugs in those areas do not pose consensus risks.

중요하게도, 주황색과 노란색 영역은 캡슐화 된 복잡성입니다. 프로토콜을 이해하려는 사람은이를 건너 뛸 수 있고, 이더 리움의 구현은 자유롭게 건너 뛸 수 있으며 해당 영역의 버그는 합의 위험을 초래하지 않습니다.

This means that code complexity in the orange and yellow areas has far fewer downsides compared to code complexity in the green area.

이는 주황색과 노란색 영역의 코드 복잡성이 녹지의 코드 복잡성에 비해 단점이 훨씬 적다는 것을 의미합니다.

To reduce the green area, we can take the following steps:

녹지를 줄이기 위해 다음 단계를 수행 할 수 있습니다.

Phase 1: New precompiles will be written in RISC-V.

1 단계 : 새로운 프리 컴파일은 RISC-V로 작성됩니다.

Phase 2: Developers will have the option to write contracts in RISC-V.

2 단계 : 개발자는 RISC-V에서 계약을 작성할 수있는 옵션이 있습니다.

Phase 3: All precompiles will be replaced with RISC-V implementations through a hard fork.

3 단계 : 모든 사전 컴파운드는 하드 포크를 통해 RISC-V 구현으로 대체됩니다.

Phase 4: We will implement an EVM interpreter in RISC-V and push it onchain as a smart contract.

4 단계 : RISC-V에서 EVM 통역사를 구현하여 스마트 계약으로 Onchain을 푸시합니다.

This way, Ethereum consensus will natively understand only RISC-V.

이런 식으로 Ethereum Consensus는 RISC-V 만 기본적으로 이해할 것입니다.

We can also share one standard across different parts of the stack.

또한 스택의 다른 부분에서 하나의 표준을 공유 할 수 있습니다.

For instance, we can use a single erasure code for data availability sampling, P2P broadcasting, and distributed history storage. This will minimize the total lines of code, increase efficiency, and ensure verifiability.

예를 들어, 데이터 가용성 샘플링, P2P 방송 및 분산 내역 저장에 단일 삭제 코드를 사용할 수 있습니다. 이렇게하면 총 코드 라인을 최소화하고 효율성을 높이며 검증 가능성을 보장합니다.

Similarly, we can have one shared serialization format across the three

마찬가지로, 우리는 세 가지에 걸쳐 하나의 공유 직렬화 형식을 가질 수 있습니다.