Vitalik: EIP-6780 là bước quan trọng trong việc đơn giản hóa giao thức Ethereum

Tác giả: Vitalik Dịch: Shan Oppa, Golden Finance

Một trong những EIP ít được biết đến hơn từ đợt hard fork Dencun gần đây là EIP-6780, loại bỏ phần lớn chức năng của opcode SELFDESTRUCT.

p>

EIP này là một ví dụ điển hình về một phần thường bị đánh giá thấp trong quá trình phát triển giao thức Ethereum:bằng cách loại bỏ sự phức tạp và thêmmớiBảo mật đảm bảo đơn giản hóa các nỗ lực giao thức. Đây là một phần quan trọng của cái mà tôi gọi là "dọn dẹp": các dự án hợp lý hóa Ethereum và xóa nợ kỹ thuật. Sẽ có nhiều EIP hơn với tinh thần tương tự, vì vậy, cần hiểu rõ cách EIP-6780 nói riêng đạt được mục tiêu của nó và những EIP khác có thể có trong tương lai.

EIP-6780 đơn giản hóa giao thức Ethereum như thế nào?

EIP-6780 làm giảm chức năng của opcode SELFDESTRUCT, điều này sẽ phá hủy hợp đồng gọi nó và xóa mã cũng như bộ nhớ của nó, do đó Nó chỉ có hiệu lực nếu hợp đồng được tạo trong cùng một giao dịch. Bản thân điều này không làm giảm độ phức tạp của đặc tả. Tuy nhiên, nó cải thiện việc triển khai bằng cách giới thiệu hai bất biến mới:

1. Sau EIP-6780, có số lượng khe lưu trữ tối đa có thể được chỉnh sửa trong một khối (khoảng: giới hạn gas / 5000).

2. Nếu hợp đồng có mã không trống khi bắt đầu giao dịch hoặc khối thì hợp đồng sẽ có mã không rỗng khi kết thúc giao dịch hoặc khối đó Cùng một mã.

Trước đây, không có bất biến nào trong số này là đúng:

1. SELFDESTRUCTCác hợp đồng có số lượng lớn khe lưu trữ có thể xóa số lượng khe lưu trữ không giới hạn trong một khối. Điều này sẽ làm cho việc triển khai cây Verkle trở nên khó khăn hơn và khiến việc triển khai ứng dụng khách Ethereum trở nên phức tạp hơn vì chúng sẽ yêu cầu mã bổ sung để xử lý trường hợp đặc biệt này một cách hiệu quả.

2. Mã của hợp đồng có thể thay đổi từ không trống thành SELFDESTRUCT trống. Trên thực tế, hợp đồng thậm chí có thể thay đổi sau khi tạo lại ngay lập tức bằng mã khác. Điều này làm cho việc xác minh giao dịch trong ví trừu tượng tài khoản trở nên khó sử dụng cơ sở mã hơn mà không dễ bị tấn công DoS.

Những bất biến này hiện tất cả đều chính xác, giúp việc xây dựng ứng dụng khách Ethereum và loại cơ sở hạ tầng khác trở nên dễ dàng hơn . Trong một vài năm nữa, người ta hy vọng rằng các EIP trong tương lai sẽ có thể hoàn thành công việc này và SELFDESTRUCT sẽ bị loại bỏ hoàn toàn.

Những cuộc "thanh lọc" nào khác đang diễn ra?

• Gần đây, Geth đã xóa hàng nghìn dòng mã, loại bỏ hỗ trợ cho các mã được hợp nhất trước (PoW ) hỗ trợ mạng.

• EIP này chính thức thể hiện thực tế là chúng ta không còn cần mã để lo lắng về "tài khoản trống" (xem: EIP-161, đã giới thiệu khái niệm này như một phần của quá trình sửa chữa cuộc tấn công DoS Thượng Hải)

• Thời hạn lưu trữ cho các đốm màu ở Dencun là 18 ngày, có nghĩa là rằng một nút Ethereum chỉ cần khoảng 50 GB để lưu trữ dữ liệu blob và số tiền này sẽ không tăng theo thời gian

Hai cái đầu tiên cải thiện đáng kể cuộc sống của các nhà phát triển khách hàng. Cái sau làm tăng đáng kể tuổi thọ của người vận hành nút.

Có thể cần phải xóa những gì khác?

Biên dịch trước

Biên dịch trước là một hợp đồng Ethereum, không có mã EVM nhưng có logic phải được thực hiện trực tiếp bởi chính khách hàng. Ý tưởng là việc biên dịch trước có thể được sử dụng để triển khai các dạng mật mã phức tạp mà không thể triển khai một cách hiệu quả trong EVM.

Ngày nay, việc sử dụng tính năng biên dịch trước rất thành công, đặc biệt là kích hoạt các ứng dụng dựa trên ZK-SNARK thông qua tính năng biên dịch trước đường cong elip. Tuy nhiên, có những trình biên dịch trước khác hiếm khi được sử dụng:

• RIPEMD-160 < /code>: Hàm băm được giới thiệu để hỗ trợ khả năng tương thích tốt hơn với Bitcoin

• Identity

  code>: Quá trình biên dịch trước trả về kết quả đầu ra giống với đầu vào của nó

• BLAKE2: Việc giới thiệu hàm băm là In để hỗ trợ khả năng tương thích tốt hơn với Zcash

• MODEXP giới thiệu hàm lũy thừa mô-đun rất lớn để hỗ trợ dựa trên Mã hóa với RSA

Hóa ra là nhu cầu về những bước biên dịch trước này nhiều thấp hơn dự kiến. Nhận dạng được sử dụng rộng rãi vì đây là cách sao chép dữ liệu dễ dàng nhất, nhưng kể từ Dencun, mã MCOPY hoạt động đã thay thế nó. Thật không may, những quá trình biên dịch trước này là nguồn gốc của các lỗi đồng thuận và là nguồn gây khó khăn lớn cho việc triển khai EVM mới, bao gồm các mạch ZK-SNARK, các triển khai thân thiện với xác minh chính thức, v.v.

Có hai cách để loại bỏ các phần biên dịch trước này:

1. Chỉ cần xóa phần biên dịch trước, vd. EIP-7266 đã xóa BLAKE2. Điều này đơn giản nhưng sẽ làm hỏng bất kỳ ứng dụng nào vẫn đang sử dụng nó.

2. Thay thế quá trình biên dịch trước bằng một khối mã EVM thực hiện điều tương tự (mặc dù chắc chắn ở mức chi phí gas cao hơn), Ví dụ. Bản dự thảo EIP này thực hiện việc này để biên dịch trước danh tính. Điều này khó khăn hơn, nhưng gần như chắc chắn sẽ không phá vỡ các ứng dụng sử dụng nó (trừ khi trong một số trường hợp hiếm hoi, chi phí gas của mã EVM mới vượt quá giới hạn gas khối cho một số đầu vào)

ol >

Lịch sử (EIP-4444)

Ngày nay, mọi nút Ethereum dự kiến ​​sẽ lưu trữ vĩnh viễn tất cả khối Lịch sử . Điều này từ lâu đã được coi là một cách tiếp cận rất lãng phí và khiến việc chạy nút Ethereum trở nên khó khăn một cách không cần thiết do yêu cầu lưu trữ cao. Ở Dencun, chúng tôi đã giới thiệu các đốm màu, chỉ cần lưu trữ trong khoảng 18 ngày. Với EIP-4444, sau một khoảng thời gian, các khối Ethereum cũng sẽ bị xóa khỏi nút Ethereum mặc định.

Một vấn đề mấu chốt cần giải quyết là: nếu lịch sử cũ không được mỗi nút lưu trữ thì dùng cái gì để lưu trữ? Vải len? Trên thực tế, các thực thể lớn như block explorer sẽ làm điều này. Tuy nhiên, cũng có thể và không khó để tạo ra một giao thức p2p để lưu trữ và truyền thông tin này, tối ưu hóa hơn cho nhiệm vụ.

Chuỗi khối Ethereum là vĩnh viễn, nhưng yêu cầu mỗi nút lưu trữ tất cả dữ liệu mãi mãi là quá mức cần thiết để đạt được Cách thức lâu dài này.

Một cách tiếp cận là mạng torrent ngang hàng đơn giản dành cho lịch sử cũ. Cái còn lại là một giao thức được tối ưu hóa rõ ràng hơn để sử dụng với Ethereum, chẳng hạn như Portal Network.

Hoặc, ở định dạng meme:



Có thể giảm dung lượng lưu trữ cần thiết để chạy nút Ethereum Tăng đáng kể số lượng người sẵn sàng làm như vậy. EIP-4444 cũng có thể giảm thời gian đồng bộ hóa nút, điều này cũng giúp đơn giản hóa quy trình làm việc cho nhiều nhà khai thác nút. Do đó, EIP-4444 có thể cải thiện đáng kể khả năng phân cấp nút của Ethereum. Có khả năng, nếu mỗi nút lưu trữ một phần nhỏ lịch sử theo mặc định, chúng tôi thậm chí có thể lưu trữ gần như cùng số lượng bản sao của từng lịch sử cụ thể trên mạng như chúng tôi làm ngày nay.

Cải cách nhật ký

Trích dẫn trực tiếp từ bản dự thảo EIP này:

Nhật ký ban đầu được giới thiệu để cho phép các ứng dụng ghi lại thông tin về các sự kiện trên chuỗi để các ứng dụng phi tập trung (dapp) có thể dễ dàng tra cứu thông tin này thông tin. Bằng cách sử dụng bộ lọc nở hoa, dapp sẽ có thể duyệt nhanh lịch sử, xác định một số khối chứa nhật ký liên quan đến ứng dụng của họ và sau đó nhanh chóng xác định giao dịch riêng lẻ nào có nhật ký được yêu cầu.

Thật ra cơ chế này quá chậm. Hầu như tất cả các dapp truy cập lịch sử đều không thông qua các lệnh gọi RPC đến các nút Ethereum (hoặc thậm chí các nút được lưu trữ từ xa), mà thông qua các dịch vụ giao thức bổ sung tập trung.

Chúng tôi có thể làm gì? Chúng ta có thể loại bỏ bộ lọc nở và đơn giản hóa mã hoạt động LOG để tất cả những gì nó làm là tạo ra một giá trị đưa hàm băm vào trạng thái. Sau đó, chúng tôi có thể xây dựng một giao thức riêng sử dụng ZK-SNARK và tính toán có thể kiểm chứng gia tăng (IVC) để tạo ra một "cây nhật ký" chính xác có thể chứng minh được, đại diện cho một bảng có thể tìm kiếm dễ dàng gồm tất cả các nhật ký được cung cấp một chủ đề và các ứng dụng cần ghi nhật ký và muốn phân cấp có thể sử dụng các giao thức riêng biệt này.

Chuyển sang SSZ

Ngày nay, hầu hết cấu trúc khối của Ethereum (bao gồm các giao dịch và biên nhận) vẫn được lưu trữ bằng định dạng lỗi thời dựa trên cây RLP và Merkle Patricia. Điều này gây khó khăn không cần thiết cho việc phát triển các ứng dụng sử dụng dữ liệu này.

Lớp đồng thuận Ethereum đã chuyển sang SimpleSerialize (SSZ) sạch hơn và hiệu quả hơn:



< em>Nguồn: https://eth2book.info/altair/part2/building_blocks/merkleization/

Tuy nhiên, chúng ta vẫn cần hoàn tất quá trình chuyển đổi và di chuyển lớp thực thi sang cùng cấu trúc.

Những ưu điểm chính của SSZ bao gồm:

• Thông số kỹ thuật đơn giản và rõ ràng hơn

• So với cây Merkle Patricia sáu nhánh hiện tại, trong hầu hết các trường hợp Merkle Độ dài của bằng chứng giảm đi 4 lần

• Độ dài của bằng chứng Merkle bị giới hạn so với độ dài cực kỳ dài trường hợp xấu nhất (ví dụ: Chứng minh mã hợp đồng hoặc đầu ra biên nhận dài)

• Không cần triển khai mã thao tác bit phức tạp (bắt buộc đối với RLP)

• Đối với các trường hợp sử dụng ZK-SNARK, thường có thể sử dụng lại các triển khai hiện có được xây dựng xung quanh cây Merkle nhị phân

Ngày nay, có ba loại cấu trúc dữ liệu được mã hóa trong Ethereum: cây nhị phân SHA256, danh sách băm SHA3 RLP và cây Patricia thập lục phân. Sau khi hoàn tất quá trình chuyển đổi sang SSZ, chúng tôi sẽ chỉ còn lại hai: cây nhị phân SHA256 và cây Verkle. Về lâu dài, khi chúng tôi đã đủ giỏi về hàm băm SNARKing, rất có thể chúng tôi sẽ thay thế cây nhị phân SHA256 và Verkle bằng cây Merkle nhị phân sử dụng hàm băm thân thiện với SNARK (cấu trúc dữ liệu mật mã hoạt động cho tất cả Cây Ethereum).