Tiêu đề gốc: Tương lai có thể có của giao thức Ethereum, phần 5: Cuộc thanh trừng
Tác giả gốc: Vitalik Buterin
Tổng hợp gốc: Chồng hàng ngày của Odaily Planet thế nào?
Kể từ ngày 14 tháng 10, người sáng lập Ethereum Vitalik Buterin đã liên tiếp công bố các cuộc thảo luận về tương lai có thể có của Ethereum, từ The Merge , The Surge , The Scourge , The Verge cho đến bản phát hành mới nhất của The Purge chứng minh Tầm nhìn của Vitalik về sự phát triển trong tương lai của mạng chính Ethereum và cách giải quyết các vấn đề hiện đang gặp phải.
The Merge: Thảo luận về sự cần thiết của Ethereum để cải thiện tính hữu hạn của một khe cắm và hạ thấp ngưỡng đặt cược sau khi chuyển sang PoS để tăng tốc độ tham gia và xác nhận giao dịch.
The Surge: khám phá các chiến lược khác nhau để mở rộng Ethereum, đặc biệt là lộ trình tập trung vào Rollup cũng như các thách thức và giải pháp của nó về khả năng mở rộng, phân cấp và bảo mật.
Tai họa: Thảo luận về những rủi ro của việc tập trung hóa và khai thác giá trị mà Ethereum phải đối mặt khi chuyển đổi sang PoS, đồng thời phát triển nhiều cơ chế khác nhau để tăng cường phân quyền và công bằng, đồng thời thực hiện cải cách kinh tế để bảo vệ lợi ích của người dùng.
The Verge: Thảo luận về những thách thức và giải pháp xác minh không trạng thái của Ethereum, tập trung vào cách các công nghệ như cây Verkle và STARK có thể nâng cao tính phân cấp và hiệu quả của chuỗi khối.
Vào ngày 26 tháng 10, Vitalik Buterin đã xuất bản một bài báo về The Purge. Bài báo thảo luận về thách thức mà Ethereum phải đối mặt là giảm độ phức tạp và yêu cầu lưu trữ về lâu dài trong khi vẫn duy trì độ bền và tính phân cấp của chuỗi. Các biện pháp chính bao gồm Giảm dung lượng lưu trữ của khách hàng. gánh nặng thông qua Hết hạn lịch sử và Hết hạn trạng thái và đơn giản hóa giao thức thông qua Làm sạch tính năng để đảm bảo tính bền vững và khả năng mở rộng của mạng.
Sau đây là nội dung gốc, được Odaily Planet Daily biên soạn.
Đặc biệt cảm ơn Justin Drake, Tim Beiko, Matt Garnett, Piper Merriam, Marius van der Wijden và Tomasz Stanczak vì những phản hồi và đánh giá của họ.
Một trong những thách thức mà Ethereum phải đối mặt là theo mặc định, sự cồng kềnh và phức tạp của bất kỳ giao thức blockchain nào sẽ tăng lên theo thời gian. Điều này xảy ra ở hai nơi:
Dữ liệu lịch sử: Mọi giao dịch được thực hiện và bất kỳ tài khoản nào được tạo tại bất kỳ thời điểm nào trong lịch sử đều cần được lưu trữ vĩnh viễn bởi tất cả khách hàng và được tải xuống bởi bất kỳ khách hàng mới nào, do đó được đồng bộ hóa hoàn toàn với mạng. Điều này khiến thời gian tải máy khách và đồng bộ hóa tăng lên theo thời gian, ngay cả khi công suất của chuỗi không đổi.
Các tính năng của giao thức: Việc thêm các tính năng mới sẽ dễ dàng hơn nhiều so với việc loại bỏ các tính năng cũ, khiến độ phức tạp của mã tăng lên theo thời gian.
Để Ethereum duy trì lâu dài, chúng ta cần có áp lực đối phó mạnh mẽ với cả hai xu hướng, giảm độ phức tạp và sự phình to theo thời gian. Nhưng đồng thời, chúng ta cần duy trì một trong những thuộc tính quan trọng làm cho blockchain trở nên tuyệt vời: tính bền bỉ. Bạn có thể đặt NFT, một bức thư tình trong dữ liệu cuộc gọi giao dịch hoặc một hợp đồng thông minh chứa 1 triệu đô la trên chuỗi, đi vào hang động trong mười năm và đi ra và thấy nó vẫn ở đó chờ bạn đọc và tương tác với nó . Để các DApp cảm thấy thoải mái khi được phân cấp hoàn toàn và loại bỏ các khóa nâng cấp, họ cần tự tin rằng các phần phụ thuộc của họ sẽ không nâng cấp theo cách phá vỡ chúng - đặc biệt là chính L1.
Nếu chúng ta quyết tâm đạt được sự cân bằng giữa hai nhu cầu này và duy trì tính liên tục đồng thời giảm thiểu hoặc đảo ngược sự phình to, phức tạp và suy giảm thì điều đó là hoàn toàn có thể. Các sinh vật có thể làm được điều này: Trong khi hầu hết các sinh vật già đi theo thời gian, một số ít may mắn thì không . Ngay cả các hệ thống xã hội cũng có thể có tuổi thọ cực kỳ dài . Trong một số trường hợp, Ethereum đã thành công: bằng chứng công việc không còn nữa, opcode SELFDESTRUCT gần như không còn nữa và các nút chuỗi beacon đã lưu trữ dữ liệu cũ có giá trị lên đến sáu tháng. Tìm ra con đường này cho Ethereum một cách tổng quát hơn và hướng tới kết quả cuối cùng là sự ổn định lâu dài, là thách thức cuối cùng đối với khả năng mở rộng lâu dài, tính bền vững kỹ thuật và thậm chí cả bảo mật của Ethereum.
Cuộc thanh trừng: Mục tiêu chính.
Giảm yêu cầu lưu trữ của máy khách bằng cách giảm hoặc loại bỏ nhu cầu mỗi nút lưu trữ vĩnh viễn tất cả lịch sử hoặc thậm chí trạng thái cuối cùng.
Giảm độ phức tạp của giao thức bằng cách loại bỏ chức năng không cần thiết.
Thư mục bài viết:
Lịch sử hết hạn
Vấn đề gì được giải quyết?
Theo văn bản này, một nút Ethereum được đồng bộ hóa hoàn toàn cần khoảng 1,1 TB dung lượng ổ đĩa cho máy khách thực thi và thêm vài trăm GB dung lượng đĩa cho máy khách đồng thuận. Phần lớn trong số đó là dữ liệu lịch sử: dữ liệu về các khối, giao dịch và biên lai lịch sử, phần lớn trong số đó đã có từ nhiều năm trước. Điều này có nghĩa là kích thước của các nút sẽ tiếp tục tăng hàng trăm GB mỗi năm ngay cả khi giới hạn gas không tăng chút nào.
Nó là gì và nó hoạt động như thế nào?
Một tính năng đơn giản hóa quan trọng của vấn đề lưu trữ lịch sử là do mỗi khối trỏ đến khối trước đó thông qua liên kết băm (và các cấu trúc khác ), nên sự đồng thuận về hiện tại là đủ để đạt được sự đồng thuận về lịch sử. Miễn là mạng đạt được sự đồng thuận về khối mới nhất, bất kỳ khối, giao dịch hoặc trạng thái lịch sử nào (số dư tài khoản, số lần sử dụng, mã, bộ lưu trữ) đều có thể được cung cấp bởi bất kỳ người tham gia nào bằng bằng chứng Merkle và bằng chứng này cho phép bất kỳ ai khác xác minh nó Sự đúng đắn. Sự đồng thuận là mô hình tin cậy N/2-of-N, trong khi lịch sử là mô hình tin cậy N-of-N .
Điều này mang lại cho chúng ta rất nhiều lựa chọn về cách lưu trữ lịch sử. Lựa chọn tự nhiên là mạng trong đó mỗi nút chỉ lưu trữ một phần nhỏ dữ liệu. Đây là cách các mạng torrent đã hoạt động trong nhiều thập kỷ: Mặc dù mạng lưu trữ và phân phối tổng cộng hàng triệu tệp nhưng mỗi người tham gia chỉ lưu trữ và phân phối một vài tệp trong số đó. Có lẽ trái ngược với trực giác, cách tiếp cận này thậm chí không nhất thiết làm cho dữ liệu trở nên kém tin cậy hơn. Nếu chúng ta có thể xây dựng một mạng lưới gồm 100.000 nút bằng cách làm cho việc chạy các nút trở nên tiết kiệm hơn, trong đó mỗi nút lưu trữ 10% lịch sử ngẫu nhiên thì mỗi phần dữ liệu sẽ được sao chép 10.000 lần - so với 10.000. Hệ số sao chép của mỗi nút hoàn toàn giống nhau - một mạng lưới các nút, mỗi nút lưu trữ mọi thứ.
Ngày nay, Ethereum đã bắt đầu thoát khỏi mô hình tất cả các nút lưu trữ vĩnh viễn tất cả lịch sử. Các khối đồng thuận (tức là các phần liên quan đến sự đồng thuận của Proof of Stake) chỉ được lưu trữ trong khoảng 6 tháng. Các đốm màu chỉ được lưu trữ trong khoảng 18 ngày. EIP-4444 nhằm mục đích giới thiệu thời gian lưu trữ một năm cho các khối và biên lai lịch sử. Mục tiêu dài hạn là thiết lập một khoảng thời gian thống nhất (có thể là khoảng 18 ngày) trong đó mỗi nút chịu trách nhiệm lưu trữ mọi thứ và sau đó thiết lập mạng lưới các nút Ethereum ngang hàng để lưu trữ dữ liệu cũ theo cách mạng phân tán.
Mã xóa có thể được sử dụng để tăng độ bền trong khi vẫn giữ nguyên hệ số sao chép. Trên thực tế, các đốm màu đã được mã hóa xóa để hỗ trợ lấy mẫu tính khả dụng của dữ liệu. Giải pháp đơn giản nhất có lẽ là sử dụng lại các mã xóa như vậy và đưa dữ liệu khối thực thi và đồng thuận vào các đốm màu.
Các kết nối với nghiên cứu hiện tại là gì?
Cần phải làm gì nữa, cần phải đánh đổi những gì?
Công việc chính còn lại bao gồm xây dựng và tích hợp một giải pháp phân tán cụ thể để lưu trữ lịch sử - ít nhất là lịch sử thực thi, nhưng cuối cùng là cả sự đồng thuận và các đốm màu. Các giải pháp đơn giản nhất là (i) chỉ cần đưa vào các thư viện torrent hiện có và (ii) giải pháp gốc Ethereum được gọi là mạng Cổng thông tin . Khi bất kỳ thứ nào trong số này được giới thiệu, chúng tôi có thể mở EIP-4444. Bản thân EIP-4444 không yêu cầu hard fork nhưng nó yêu cầu phiên bản giao thức mạng mới. Do đó, việc kích hoạt tính năng này cho tất cả khách hàng cùng một lúc là rất có giá trị, nếu không sẽ có nguy cơ khách hàng không kết nối được với các nút khác với mong muốn tải xuống toàn bộ lịch sử nhưng thực tế không nhận được nó.
Sự đánh đổi chính liên quan đến cách chúng tôi cố gắng cung cấp dữ liệu lịch sử cổ xưa. Giải pháp đơn giản nhất là ngừng lưu trữ lịch sử cổ đại vào ngày mai và dựa vào các nút lưu trữ hiện có cũng như các nhà cung cấp tập trung khác nhau để nhân rộng. Điều đó thật dễ dàng, nhưng nó làm suy yếu vị thế của Ethereum như một nơi lưu trữ lâu dài. Con đường khó khăn hơn nhưng an toàn hơn là trước tiên xây dựng và tích hợp mạng torrent để lưu trữ lịch sử theo cách phân tán. Ở đây, “chúng ta cố gắng thế nào” có hai khía cạnh:
Làm cách nào để chúng tôi cố gắng đảm bảo rằng tập hợp nút lớn nhất thực sự lưu trữ tất cả dữ liệu?
Chúng tôi tích hợp lưu trữ lịch sử vào giao thức sâu đến mức nào?
Một cách tiếp cận cực kỳ hoang tưởng đối với (1) sẽ liên quan đến bằng chứng ký quỹ : yêu cầu mỗi người xác thực bằng chứng cổ phần phải lưu trữ một tỷ lệ phần trăm lịch sử nhất định và kiểm tra bằng mật mã định kỳ xem họ có làm như vậy không. Một cách tiếp cận khiêm tốn hơn sẽ là đặt ra một tiêu chuẩn tự nguyện cho tỷ lệ phần trăm lịch sử mà mỗi khách hàng lưu trữ.
Đối với (2), việc triển khai cơ bản chỉ liên quan đến công việc đã được hoàn thành ngày hôm nay: Cổng thông tin đã lưu trữ tệp ERA chứa toàn bộ lịch sử của Ethereum. Việc triển khai kỹ lưỡng hơn sẽ liên quan đến việc thực sự kết nối nó với quy trình đồng bộ hóa, để nếu ai đó muốn đồng bộ hóa nút lưu trữ lịch sử đầy đủ hoặc nút lưu trữ, họ có thể làm như vậy bằng cách đồng bộ hóa trực tiếp từ mạng cổng thông tin, ngay cả khi không có nút lưu trữ nào khác tồn tại trực tuyến.
Nó tương tác với các phần khác của lộ trình như thế nào?
Nếu chúng tôi muốn làm cho việc chạy hoặc khởi động một nút trở nên cực kỳ dễ dàng, thì việc giảm yêu cầu lưu trữ lịch sử được cho là quan trọng hơn tình trạng không trạng thái: trong số 1,1 TB mà nút yêu cầu, ~300 GB là trạng thái và ~800 GB còn lại là lịch sử. Chỉ bằng cách triển khai trạng thái không trạng thái và EIP-4444, tầm nhìn chạy nút Ethereum trên đồng hồ thông minh và chỉ mất vài phút để thiết lập mới có thể thành hiện thực.
Việc hạn chế lưu trữ lịch sử cũng giúp việc triển khai nút Ethereum mới hơn chỉ khả thi hơn khi chỉ hỗ trợ phiên bản mới nhất của giao thức, điều này làm cho chúng đơn giản hơn. Ví dụ: nhiều dòng mã hiện có thể được gỡ bỏ một cách an toàn vì các khe lưu trữ trống được tạo trong cuộc tấn công DoS 2016 đều đã bị xóa . Giờ đây, việc chuyển sang Proof-of-Stake đã là lịch sử, khách hàng có thể xóa tất cả mã liên quan đến Proof-of-Work một cách an toàn.
Trạng thái hết hạn
Vấn đề gì được giải quyết?
Ngay cả khi chúng tôi loại bỏ nhu cầu lưu trữ lịch sử của khách hàng, yêu cầu về dung lượng lưu trữ của khách hàng sẽ tiếp tục tăng, ở mức khoảng 50 GB mỗi năm, khi trạng thái tiếp tục tăng: số dư tài khoản và số dư tài khoản, mã hợp đồng và dung lượng lưu trữ hợp đồng. Người dùng có thể trả phí một lần, tạo gánh nặng mãi mãi cho khách hàng Ethereum hiện tại và tương lai.
Trạng thái khó hết hạn hơn lịch sử vì EVM về cơ bản được thiết kế dựa trên giả định rằng một khi đối tượng trạng thái được tạo, nó luôn tồn tại và có thể được đọc bởi bất kỳ giao dịch nào vào bất kỳ lúc nào. Một số ý kiến cho rằng vấn đề này có thể không quá tệ nếu chúng ta đưa vào trạng thái không trạng thái: chỉ lớp xây dựng khối chuyên dụng mới thực sự lưu trữ trạng thái, trong khi tất cả các nút khác (thậm chí cả việc tạo danh sách!) Có thể chạy không trạng thái. Tuy nhiên, có một lập luận được đưa ra rằng chúng tôi không muốn phụ thuộc quá nhiều vào tình trạng không quốc tịch và cuối cùng chúng tôi có thể muốn hết hạn các trạng thái để giữ cho Ethereum được phân cấp.
nó là gì và nó hoạt động như thế nào
Ngày nay, khi bạn tạo một đối tượng trạng thái mới (có thể xảy ra theo một trong ba cách: (i) gửi ETH đến tài khoản mới, (ii) tạo tài khoản mới bằng mã, (iii) thiết lập khe lưu trữ chưa được chạm tới trước đó), đối tượng trạng thái luôn ở trạng thái này. Thay vào đó, điều chúng ta muốn là các đối tượng sẽ tự động hết hạn theo thời gian. Thách thức chính là thực hiện điều này theo cách đạt được ba mục tiêu:
Hiệu quả: Không cần tính toán bổ sung rộng rãi để chạy quá trình hết hạn.
Thân thiện với người dùng: Nếu ai đó vào hang trong 5 năm và quay lại, họ sẽ không mất quyền truy cập vào các vị trí ETH, ERC 20, NFT, CDP…
Thân thiện với nhà phát triển: Nhà phát triển không cần phải chuyển sang một mô hình tinh thần hoàn toàn xa lạ. Ngoài ra, các ứng dụng hiện đã cũ và chưa được cập nhật sẽ tiếp tục hoạt động bình thường.
Không đạt được những mục tiêu này có thể dễ dàng dẫn đến các vấn đề. Ví dụ: bạn có thể yêu cầu mỗi đối tượng trạng thái cũng lưu trữ bộ đếm ngày hết hạn (ngày hết hạn có thể được kéo dài bằng cách đốt ETH, điều này có thể tự động xảy ra bất cứ khi nào thực hiện đọc hoặc ghi) và có một vòng lặp lặp lại trạng thái để loại bỏ đối tượng trạng thái quá trình ngày hết hạn. Tuy nhiên, điều này đưa ra tính toán bổ sung (và thậm chí cả yêu cầu lưu trữ) và chắc chắn nó không đáp ứng được yêu cầu về tính thân thiện với người dùng. Các nhà phát triển cũng khó giải thích về các trường hợp Edge liên quan đến các giá trị được lưu trữ đôi khi bị đặt lại về 0. Nếu bạn đặt bộ hẹn giờ hết hạn trong hợp đồng, về mặt kỹ thuật, điều này giúp cuộc sống của nhà phát triển dễ dàng hơn nhưng lại gây khó khăn hơn về mặt kinh tế: nhà phát triển phải suy nghĩ về cách chuyển chi phí lưu trữ liên tục cho người dùng.
Đây là những vấn đề mà cộng đồng phát triển cốt lõi Ethereum đã phải vật lộn trong nhiều năm, bao gồm các đề xuất như “ Cho thuê Blockchain ” và “ Tái tạo ”. Cuối cùng, chúng tôi đã kết hợp những phần hay nhất của đề xuất và tập trung vào hai loại giải pháp tồi tệ nhất ít được biết đến nhất:
Giải pháp hết hạn trạng thái một phần
Đề xuất hết hạn dựa trên khoảng thời gian địa chỉ.
Trạng thái hết hạn một phần Trạng thái hết hạn một phần
Tất cả các đề xuất hết hạn trạng thái một phần đều tuân theo các nguyên tắc giống nhau. Chúng tôi chia nhà nước thành nhiều phần. Mọi người đều lưu trữ vĩnh viễn một bản đồ cấp cao nhất gồm các khối trống hoặc không trống. Dữ liệu trong mỗi khối chỉ được lưu trữ nếu dữ liệu đó được truy cập gần đây. Có cơ chế “hồi sinh” nếu không còn lưu trữ
Sự khác biệt chính giữa các đề xuất này là: (i) làm cách nào để chúng tôi xác định gần nhất và (ii) làm cách nào để xác định đoạn? Một đề xuất cụ thể là EIP-7736 , được xây dựng dựa trên thiết kế thân-lá được giới thiệu cho cây Verkle (mặc dù tương thích với mọi dạng trạng thái không trạng thái, chẳng hạn như cây nhị phân). Trong thiết kế này, các tiêu đề, mã và vị trí liền kề nhau sẽ được lưu trữ trong cùng một thân cây. Lượng dữ liệu tối đa được lưu trữ dưới một thân có thể là 256 * 31 = 7.936 byte. Trong nhiều trường hợp, toàn bộ tiêu đề và mã của tài khoản sẽ được lưu trữ trong cùng một đường trục cũng như nhiều khe lưu trữ chính. Nếu dữ liệu trong một đường trục nhất định không được đọc hoặc ghi trong 6 tháng thì dữ liệu đó sẽ không được lưu trữ nữa mà chỉ lưu trữ cam kết 32 byte (sơ khai) của dữ liệu đó. Các giao dịch trong tương lai truy cập vào dữ liệu này sẽ cần phải khôi phục dữ liệu và cung cấp bằng chứng kiểm tra sơ khai.
Có nhiều cách khác để thực hiện những ý tưởng tương tự. Ví dụ: nếu mức độ chi tiết ở cấp tài khoản là không đủ, chúng tôi có thể phát triển một sơ đồ trong đó mỗi 1/2 32 phần của cây được kiểm soát bằng cơ chế thân và lá tương tự.
Điều này trở nên phức tạp hơn do có các biện pháp khuyến khích: kẻ tấn công có thể cập nhật cây bằng cách đưa nhiều dữ liệu vào một cây con và gửi một giao dịch mỗi năm, buộc khách hàng phải lưu trữ vĩnh viễn nhiều trạng thái. Nếu bạn đặt chi phí gia hạn tỷ lệ thuận với kích thước cây (hoặc tỷ lệ nghịch với thời gian gia hạn), thì ai đó có thể gây tổn hại cho những người dùng khác bằng cách đưa nhiều dữ liệu vào cùng cây con với họ. Người ta có thể cố gắng hạn chế cả hai vấn đề bằng cách làm cho độ chi tiết động theo kích thước cây con: ví dụ: mỗi đối tượng trạng thái 2 16 = 65536 liên tiếp có thể được coi là một nhóm. Tuy nhiên, những ý tưởng này phức tạp hơn; các cách tiếp cận dựa trên gốc rất đơn giản và có thể điều chỉnh các khuyến khích vì thông thường tất cả dữ liệu trong một gốc đều liên quan đến cùng một ứng dụng hoặc người dùng.
Đề xuất hết hạn của tiểu bang dựa trên khoảng thời gian địa chỉ
Điều gì sẽ xảy ra nếu chúng ta muốn tránh hoàn toàn mọi sự tăng trưởng trạng thái cố định, thậm chí cả sơ khai 32 byte? Do xung đột phục hồi , đây là một câu hỏi khó: điều gì sẽ xảy ra nếu một đối tượng trạng thái bị xóa và việc thực thi EVM sau đó đặt một đối tượng trạng thái khác vào cùng một vị trí, nhưng sau đó ai đó quan tâm đến đối tượng trạng thái ban đầu quay lại và cố gắng khôi phục nó thì sao? Stubbing ngăn không cho dữ liệu mới được tạo khi một phần trạng thái hết hạn. Với trạng thái hoàn toàn hết hạn, chúng tôi thậm chí không thể lưu trữ sơ khai.
Thiết kế dựa trên chu trình địa chỉ là ý tưởng nổi tiếng nhất để giải quyết vấn đề này. Thay vì có một cây trạng thái để lưu trữ toàn bộ trạng thái, chúng ta có một danh sách cây trạng thái ngày càng tăng và mọi trạng thái được đọc hoặc ghi đều được lưu trong cây trạng thái mới nhất. Một cây trạng thái trống mới được thêm vào mỗi kỳ (ví dụ: 1 năm). Những cây cổ thụ đã bị đóng băng hoàn toàn. Các nút đầy đủ chỉ lưu trữ hai cây gần nhất. Nếu một đối tượng trạng thái không được chạm vào trong hai chu kỳ, do đó rơi vào cây hết hạn, nó vẫn có thể được đọc hoặc ghi, nhưng giao dịch cần chứng minh bằng chứng Merkle của nó - sau khi được chứng minh, một bản sao sẽ được lưu lại muộn nhất trong cây.
Ý tưởng chính giúp điều này trở nên thân thiện với cả người dùng và nhà phát triển là khái niệm về chu kỳ địa chỉ. Khoảng thời gian địa chỉ là số là một phần của địa chỉ. Nguyên tắc chính là địa chỉ có chu kỳ địa chỉ N chỉ có thể được đọc hoặc ghi trong hoặc sau giai đoạn N (tức là khi danh sách cây trạng thái đạt đến độ dài N). Nếu bạn muốn lưu một đối tượng trạng thái mới (ví dụ: hợp đồng mới hoặc số dư ERC 20 mới), nếu bạn đảm bảo đặt đối tượng trạng thái vào hợp đồng có chu kỳ địa chỉ N hoặc N-1, thì bạn có thể lưu Hãy làm điều đó ngay lập tức mà không đưa ra bằng chứng rằng trước đó không có gì cả. Mặt khác, bất kỳ bổ sung hoặc chỉnh sửa nào được thực hiện trong thời hạn địa chỉ cũ sẽ cần có bằng chứng.
Thiết kế này giữ lại hầu hết các thuộc tính hiện tại của Ethereum và không yêu cầu tính toán bổ sung, cho phép các ứng dụng được viết gần như như hiện tại (ERC 20 cần được viết lại để đảm bảo rằng số dư địa chỉ với chu kỳ địa chỉ N được lưu trữ trong các hợp đồng phụ, bản thân chúng có một địa chỉ kỳ N), giải quyết được vấn đề “người dùng đã ở trong hang được 5 năm”. Tuy nhiên, nó có một vấn đề lớn: địa chỉ cần được mở rộng vượt quá 20 byte để phù hợp với chu kỳ địa chỉ.
Mở rộng không gian địa chỉ Mở rộng không gian địa chỉ
Một đề xuất là giới thiệu định dạng địa chỉ 32 byte mới bao gồm số phiên bản, số chu kỳ địa chỉ và hàm băm mở rộng.
0x 01 (đỏ) 0000 (cam) 000001 (xanh) 57 aE 408398 dF 7 E 5 f 4552091 MỘT 69125 d5 fc 7 B 8 C 2659029395 bdF (màu xanh).
Màu đỏ là số phiên bản. Bốn số 0 màu cam ở đây nhằm mục đích là các khoảng trống có thể chứa số phân đoạn trong tương lai. Màu xanh lá cây là số chu kỳ địa chỉ. Màu xanh là giá trị băm 26 byte.
Thách thức chính ở đây là khả năng tương thích ngược. Các hợp đồng hiện tại được thiết kế xung quanh các địa chỉ 20 byte và thường sử dụng các kỹ thuật đóng gói byte nghiêm ngặt, giả định rõ ràng rằng các địa chỉ có độ dài chính xác là 20 byte. Một ý tưởng để giải quyết vấn đề này liên quan đến ánh xạ dịch thuật, trong đó các hợp đồng kiểu cũ tương tác với các địa chỉ kiểu mới sẽ thấy hàm băm 20 byte của địa chỉ kiểu mới. Tuy nhiên, có sự phức tạp đáng kể trong việc đảm bảo an ninh của nó.
Thu hẹp không gian địa chỉ
Một cách tiếp cận khác có hướng ngược lại: chúng tôi ngay lập tức cấm một số dải địa chỉ con có kích thước 2 128 (ví dụ: tất cả các địa chỉ bắt đầu bằng 0x ffffffff), sau đó sử dụng dải đó để giới thiệu các địa chỉ có chu kỳ địa chỉ và hàm băm 14 byte.
0x ffffffff 000169125 d5 fc 7 B 8 C2659029395bdF
Sự hy sinh chính của phương pháp này là gây ra rủi ro bảo mật của các địa chỉ phản thực : các địa chỉ chứa tài sản hoặc quyền, nhưng mã của chúng chưa được xuất bản lên chuỗi. Rủi ro liên quan đến việc ai đó tạo một địa chỉ tuyên bố sở hữu một đoạn mã (chưa được phát hành), nhưng cũng có một đoạn mã hợp lệ khác được băm vào cùng một địa chỉ. Việc tính toán một xung đột như vậy ngày nay sẽ cần tới 280 giá trị băm; việc thu hẹp không gian địa chỉ sẽ giảm con số này xuống còn 256 giá trị băm có thể truy cập dễ dàng.
Lĩnh vực rủi ro chính, địa chỉ giả cho các ví do nhiều chủ sở hữu nắm giữ, ngày nay tương đối hiếm nhưng có thể sẽ trở nên phổ biến hơn khi chúng ta chuyển sang thế giới đa L2. Giải pháp duy nhất là chấp nhận rủi ro này nhưng xác định tất cả các trường hợp sử dụng phổ biến có thể phát sinh vấn đề và đưa ra cách giải quyết hiệu quả.
Các kết nối với nghiên cứu hiện tại là gì?
đề xuất sớm
Đề xuất đã hết hạn trạng thái một phần
EIP-7736 ;
Tài liệu mở rộng không gian địa chỉ
Cần phải làm gì nữa, cần phải đánh đổi những gì?
Tôi nghĩ có bốn con đường khả thi cho tương lai:
Chúng tôi không có trạng thái và không bao giờ giới thiệu trạng thái hết hạn. Trạng thái đang phát triển (mặc dù chậm: chúng ta có thể sẽ không thấy nó vượt quá 8 TB trong nhiều thập kỷ), mà chỉ bởi một nhóm người dùng tương đối đặc biệt: ngay cả trình xác thực PoS cũng không yêu cầu trạng thái.
Một tính năng yêu cầu quyền truy cập vào một phần trạng thái là tạo danh sách bao gồm, nhưng chúng tôi có thể thực hiện việc này theo cách phi tập trung: mỗi người dùng chịu trách nhiệm duy trì phần cây trạng thái chứa tài khoản của riêng họ. Khi họ phát một giao dịch, họ sẽ phát nó kèm theo bằng chứng về đối tượng trạng thái được truy cập trong bước xác minh (điều này áp dụng cho các tài khoản EOA và ERC-4337). Sau đó, trình xác nhận không có trạng thái có thể kết hợp các bằng chứng này thành một bằng chứng chứa toàn bộ danh sách.Chúng tôi thực hiện hết hạn trạng thái một phần và chấp nhận tốc độ tăng trưởng kích thước trạng thái vĩnh viễn thấp hơn nhiều nhưng vẫn khác 0. Kết quả này được cho là tương tự như cách các đề xuất hết hạn lịch sử liên quan đến mạng ngang hàng chấp nhận tốc độ tăng trưởng lưu trữ lịch sử vĩnh viễn thấp hơn nhiều nhưng vẫn khác 0, trong đó mỗi khách hàng phải lưu trữ tỷ lệ phần trăm dữ liệu lịch sử thấp hơn nhưng cố định.
Chúng tôi hết hạn trạng thái thông qua việc mở rộng không gian địa chỉ. Điều này sẽ bao gồm một quy trình kéo dài nhiều năm để đảm bảo rằng phương thức chuyển đổi định dạng địa chỉ có hiệu quả và an toàn, bao gồm cả các ứng dụng hiện có.
Chúng tôi thực hiện hết hạn trạng thái thông qua việc thu hẹp không gian địa chỉ. Điều này sẽ bao gồm một quy trình kéo dài nhiều năm để đảm bảo rằng tất cả các rủi ro bảo mật liên quan đến xung đột địa chỉ, bao gồm các tình huống xuyên chuỗi, đều được giải quyết.
Điểm quan trọng là liệu kế hoạch hết hạn trạng thái dựa trên thay đổi định dạng địa chỉ có được triển khai hay không thì cuối cùng các vấn đề khó khăn xung quanh việc mở rộng và thu hẹp không gian địa chỉ cũng phải được giải quyết. Ngày nay, việc tạo ra xung đột địa chỉ cần khoảng 2 80 giá trị băm và tải tính toán này đã khả thi đối với các tác nhân cực kỳ giàu tài nguyên: GPU có thể thực hiện khoảng 2 27 giá trị băm, do đó hoạt động trong một năm 2 52, do đó có khoảng 2 30 GPU trong tất cả các địa chỉ. thế giới có thể tính toán một vụ va chạm trong khoảng 1/4 năm, và FPGA và ASIC có thể đẩy nhanh quá trình này hơn nữa. Trong tương lai, những cuộc tấn công như vậy sẽ ngày càng mở ra cho nhiều người hơn. Do đó, chi phí thực tế của việc thực hiện hết hạn trạng thái đầy đủ có thể không cao như người ta tưởng, vì dù sao thì chúng ta cũng phải giải quyết vấn đề địa chỉ đầy thách thức này.
Nó tương tác với các phần khác của lộ trình như thế nào?
Việc thực hiện hết hạn trạng thái có thể giúp chuyển đổi từ định dạng cây trạng thái này sang định dạng cây trạng thái khác dễ dàng hơn vì không cần quá trình chuyển đổi: bạn chỉ cần bắt đầu tạo cây mới theo định dạng mới và sau đó thực hiện phân nhánh cứng để Chuyển đổi cây cũ. Vì vậy, mặc dù việc hết hạn trạng thái rất phức tạp nhưng nó có lợi ích là đơn giản hóa các khía cạnh khác của lộ trình.
Dọn dẹp tính năng
Nó giải quyết được vấn đề gì?
Một trong những điều kiện tiên quyết quan trọng để đảm bảo tính bảo mật, khả năng truy cập và tính trung lập đáng tin cậy là tính đơn giản. Nếu giao thức đẹp và đơn giản thì sẽ ít xảy ra lỗi hơn. Nó làm tăng cơ hội cho các nhà phát triển mới có thể tham gia vào bất kỳ phần nào của nó. Nó có nhiều khả năng công bằng hơn và chống lại các lợi ích đặc biệt hơn. Thật không may, các giao thức, giống như bất kỳ hệ thống xã hội nào, theo mặc định trở nên phức tạp hơn theo thời gian. Nếu không muốn Ethereum rơi vào lỗ đen ngày càng phức tạp, chúng ta cần thực hiện một trong hai điều: (i) ngừng thực hiện các thay đổi và củng cố giao thức, (ii) có thể thực sự loại bỏ các tính năng và giảm độ phức tạp. Cũng có thể sử dụng một đường dẫn ở giữa, một đường dẫn ít thay đổi giao thức hơn và loại bỏ ít nhất một chút phức tạp theo thời gian. Phần này thảo luận về cách giảm bớt hoặc loại bỏ sự phức tạp.
Nó là gì và nó hoạt động như thế nào?
Không có cách khắc phục lớn nào có thể làm giảm độ phức tạp của giao thức; bản chất của vấn đề là có nhiều giải pháp nhỏ.
Một ví dụ gần như đã hoàn tất là việc loại bỏ opcode SELFDESTRUCT và có thể dùng làm bản thiết kế chi tiết về cách tiếp cận các ví dụ khác. Opcode SELFDESTRUCT là opcode duy nhất có thể sửa đổi số lượng khe lưu trữ không giới hạn trong một khối duy nhất, yêu cầu khách hàng triển khai độ phức tạp cao hơn đáng kể để tránh các cuộc tấn công DoS. Mục đích ban đầu của opcode này là cho phép thanh lý trạng thái tự nguyện, cho phép giảm kích thước trạng thái theo thời gian. Trên thực tế, rất ít người sử dụng nó. Opcode đã bị suy yếu để chỉ cho phép các tài khoản tự hủy được tạo trong cùng một giao dịch với hard fork Dencun. Điều này giải quyết các vấn đề DoS và đơn giản hóa đáng kể mã máy khách. Trong tương lai, việc loại bỏ hoàn toàn opcode có thể là điều hợp lý.
Một số ví dụ chính về các cơ hội đơn giản hóa giao thức được xác định cho đến nay bao gồm: Đầu tiên, một số ví dụ bên ngoài EVM; đây là những ví dụ tương đối không xâm lấn và do đó dễ dàng đạt được sự đồng thuận và thực hiện trong thời gian ngắn hơn.
Chuyển đổi RLP → SSZ: Ban đầu, các đối tượng Ethereum được tuần tự hóa bằng cách sử dụng mã hóa có tên RLP . RLP không có kiểu chữ và phức tạp không cần thiết. Ngày nay, beacon chain sử dụng SSZ , tốt hơn đáng kể về nhiều mặt, bao gồm cả việc hỗ trợ không chỉ tuần tự hóa mà còn hỗ trợ băm. Cuối cùng, chúng tôi hy vọng sẽ loại bỏ hoàn toàn RLP và chuyển tất cả các loại dữ liệu sang cấu trúc SSZ, điều này sẽ giúp việc nâng cấp dễ dàng hơn. Các EIP hiện tại bao gồm [1] [2] [3] .
Xóa các loại giao dịch cũ: Hiện nay có quá nhiều loại giao dịch và nhiều loại trong số đó có thể bị xóa. Một giải pháp thay thế nhẹ nhàng hơn để loại bỏ hoàn toàn là tính năng Trừu tượng tài khoản, theo đó tài khoản thông minh có thể bao gồm mã để xử lý và xác minh các giao dịch cũ nếu họ chọn.
Cải cách LOG: Nhật ký tạo các bộ lọc nở hoa và logic khác làm tăng độ phức tạp của giao thức nhưng thực tế không được khách hàng sử dụng vì nó quá chậm. Chúng tôi có thể loại bỏ các tính năng này và thay vào đó nghiên cứu các giải pháp thay thế, chẳng hạn như các công cụ đọc nhật ký phi tập trung ngoài giao thức sử dụng các công nghệ hiện đại như SNARK.
Cơ chế ủy ban đồng bộ hóa chuỗi đèn hiệu cuối cùng đã bị loại bỏ: Cơ chế ủy ban đồng bộ hóa ban đầu được giới thiệu để cho phép xác minh ứng dụng khách nhẹ của Ethereum. Tuy nhiên, nó làm tăng đáng kể độ phức tạp của giao thức. Cuối cùng, chúng tôi sẽ có thể xác minh trực tiếp lớp đồng thuận Ethereum bằng cách sử dụng SNARK , điều này sẽ loại bỏ nhu cầu về các giao thức xác minh ứng dụng khách hạng nhẹ chuyên dụng. Có khả năng, những thay đổi đối với sự đồng thuận có thể cho phép chúng tôi loại bỏ ủy ban đồng bộ hóa sớm hơn bằng cách tạo ra một giao thức máy khách nhẹ “bản địa” hơn bao gồm việc xác thực chữ ký từ một tập hợp con ngẫu nhiên của trình xác thực đồng thuận Ethereum.
Các định dạng dữ liệu hợp nhất: Ngày nay, trạng thái thực thi được lưu trữ trong cây Merkle Patricia, trạng thái đồng thuận được lưu trữ trong cây SSZ và các đốm màu được cam kết thông qua cam kết KZG . Trong tương lai, sẽ rất hợp lý nếu có một định dạng thống nhất duy nhất cho dữ liệu khối và một định dạng thống nhất duy nhất cho trạng thái. Các định dạng này sẽ đáp ứng tất cả các yêu cầu quan trọng: (i) bằng chứng đơn giản về các máy khách không có trạng thái, (ii) mã hóa tuần tự và xóa dữ liệu, (iii) cấu trúc dữ liệu được tiêu chuẩn hóa.
Loại bỏ Ủy ban Chuỗi Beacon: Cơ chế này ban đầu được giới thiệu để hỗ trợ một phiên bản phân đoạn thực thi cụ thể . Thay vào đó, chúng tôi kết thúc việc phân chia thông qua L2 và blobs . Do đó, ủy ban này là không cần thiết và hành động đang được thực hiện để loại bỏ nó .
Loại bỏ endian hỗn hợp: EVM là endian lớn và lớp đồng thuận là endian nhỏ. Có thể hợp lý hơn nếu điều chỉnh lại và làm mọi thứ theo cách này hay cách khác (có thể là endian lớn vì EVM khó thay đổi hơn)
Bây giờ, một số ví dụ trong EVM:
Đơn giản hóa cơ chế Gas: Các quy tắc Gas hiện tại chưa được tối ưu hóa tốt và không thể đưa ra giới hạn rõ ràng về số lượng tài nguyên cần thiết để xác minh các khối. Các ví dụ chính về điều này bao gồm (i) chi phí đọc/ghi lưu trữ, được thiết kế để giới hạn số lần đọc/ghi trong một khối nhưng hiện khá tùy ý và (ii) các quy tắc lấp đầy bộ nhớ, hiện khó ước tính mức tối đa. mức tiêu thụ bộ nhớ của EVM. Các biện pháp khắc phục được đề xuất bao gồm các thay đổi về chi phí gas không trạng thái nhằm thống nhất tất cả các chi phí liên quan đến lưu trữ thành một công thức đơn giản và đề xuất định giá bộ nhớ .
Loại bỏ các phần biên dịch trước: Nhiều phần tiền biên dịch mà Ethereum hiện có đều phức tạp không cần thiết, tương đối không được sử dụng và tạo thành một phần lớn các lỗi đồng thuận trong khi hầu như không được sử dụng bởi bất kỳ ứng dụng nào. Hai cách để giải quyết vấn đề này là (i) chỉ loại bỏ quá trình biên dịch trước và (ii) thay thế nó bằng một đoạn mã EVM (chắc chắn đắt hơn) thực hiện cùng một logic. Dự thảo EIP khuyến nghị thực hiện việc này để biên dịch trước danh tính như là bước đầu tiên sau này, RIPEMD 160, MODEXP và BLAKE có thể trở thành ứng cử viên để loại bỏ.
Loại bỏ khả năng quan sát khí: Làm cho việc thực thi EVM không còn thấy lượng khí còn lại. Điều này sẽ phá vỡ một số ứng dụng (đáng chú ý nhất là các hợp đồng tài trợ), nhưng sẽ giúp nâng cấp dễ dàng hơn trong tương lai (ví dụ: đối với các phiên bản khí đa chiều cao cấp hơn). Đặc tả EOF đã làm cho Gas không thể quan sát được, nhưng để đơn giản hóa giao thức, EOF cần phải trở thành bắt buộc.
Những cải tiến trong phân tích tĩnh: Mã EVM ngày nay khó phân tích tĩnh, đặc biệt vì các bước nhảy có thể là động. Điều này cũng làm cho việc tối ưu hóa việc triển khai EVM (biên dịch trước mã EVM sang các ngôn ngữ khác) trở nên khó khăn hơn. Chúng tôi có thể giải quyết vấn đề này bằng cách loại bỏ các bước nhảy động (hoặc làm cho chúng đắt hơn, ví dụ: chi phí gas tuyến tính cho tổng số JUMPDEST trong hợp đồng). EOF thực hiện điều đó, mặc dù việc thực thi EOF là cần thiết để thu được lợi ích đơn giản hóa giao thức từ nó.
Các kết nối với nghiên cứu hiện tại là gì?
Một phương pháp truy xuất nhật ký an toàn ngoài chuỗi bằng cách sử dụng tính toán có thể xác minh tăng dần (đọc: STARK đệ quy);
Cần phải làm gì nữa, cần phải đánh đổi những gì?
Sự đánh đổi chính trong việc đơn giản hóa tính năng này là (i) mức độ và tốc độ đơn giản hóa của chúng tôi so với (ii) khả năng tương thích ngược. Giá trị của Ethereum như một chuỗi xuất phát từ thực tế rằng nó là một nền tảng nơi bạn có thể triển khai một ứng dụng và tin tưởng rằng nó vẫn sẽ hoạt động trong nhiều năm sau đó. Đồng thời, lý tưởng này có thể đi quá xa, và theo cách nói của William Jennings Bryan , “đảm bảo Ethereum phải vượt qua khả năng tương thích ngược”. Nếu chỉ có hai ứng dụng trong toàn bộ Ethereum sử dụng một tính năng nhất định và một ứng dụng không có người dùng trong nhiều năm, trong khi ứng dụng kia gần như hoàn toàn không được sử dụng và đạt được tổng giá trị là 57 USD, thì chúng ta nên loại bỏ chức năng đó và trả cho nạn nhân 57 USD tiền túi nếu cần thiết.
Vấn đề xã hội rộng hơn là tạo ra một quy trình tiêu chuẩn hóa để thực hiện các thay đổi vi phạm khả năng tương thích ngược không khẩn cấp. Một cách để tiếp cận vấn đề này là kiểm tra và mở rộng các tiền lệ hiện có, chẳng hạn như các quá trình tự hủy diệt. Đường ống trông như thế này:
Bắt đầu nói về việc loại bỏ tính năng X;
Tiến hành phân tích để xác định tác động của việc loại bỏ và tiếp tục;
Phát triển EIP chính thức để loại bỏ X. Đảm bảo cơ sở hạ tầng phổ biến cấp cao hơn (ví dụ: ngôn ngữ lập trình, ví) tôn trọng điều này và ngừng sử dụng tính năng này. ;
Cuối cùng, thực sự xóa X;
Cần có một lộ trình kéo dài nhiều năm giữa bước 1 và bước 4, với hướng dẫn rõ ràng về dự án nào đang ở bước nào. Tại thời điểm này, có sự cân bằng giữa tính năng động và tốc độ của quá trình loại bỏ tính năng so với việc thận trọng hơn và dành nhiều tài nguyên hơn cho các lĩnh vực phát triển giao thức khác, nhưng chúng ta vẫn còn cách xa biên giới Pareto.
EOF
Một tập hợp các thay đổi chính được đề xuất đối với EVM là Định dạng đối tượng EVM (EOF) . EOF giới thiệu một số lượng lớn các thay đổi, chẳng hạn như vô hiệu hóa khả năng quan sát khí, khả năng quan sát mã (tức là không có CODECOPY) và chỉ cho phép nhảy tĩnh. Mục tiêu là cho phép nâng cấp EVM nhiều hơn với các đặc tính mạnh hơn trong khi vẫn duy trì khả năng tương thích ngược (vì EVM trước EOF vẫn tồn tại).
Ưu điểm của việc này là nó tạo ra một lộ trình tự nhiên để thêm chức năng EVM mới và khuyến khích chuyển đổi sang EVM chặt chẽ hơn với những đảm bảo mạnh mẽ hơn. Nhược điểm là nó làm tăng đáng kể độ phức tạp của giao thức, trừ khi chúng ta có thể tìm ra cách để loại bỏ EVM cũ. Câu hỏi chính là: EOF đóng vai trò gì trong các đề xuất đơn giản hóa EVM, đặc biệt nếu mục tiêu là giảm độ phức tạp tổng thể của EVM?
Nó tương tác với các phần khác của lộ trình như thế nào?
Nhiều gợi ý “cải tiến” trong phần còn lại của lộ trình cũng là cơ hội để đơn giản hóa các tính năng cũ. Lặp lại một số ví dụ ở trên:
Việc chuyển sang tính năng cuối cùng một khe cho chúng tôi cơ hội loại bỏ các ủy ban, thiết kế lại nền kinh tế và thực hiện các đơn giản hóa khác liên quan đến bằng chứng cổ phần.
Việc triển khai đầy đủ tính năng trừu tượng hóa tài khoản cho phép chúng tôi loại bỏ nhiều logic xử lý giao dịch hiện có và chuyển nó vào mã EVM tài khoản mặc định mà tất cả EOA đều có thể thay thế.
Điều này có thể được điều hòa với các phiên bản SSZ mới nếu chúng ta chuyển trạng thái Ethereum sang cây băm nhị phân để tất cả các cấu trúc dữ liệu Ethereum có thể được băm theo cùng một cách.
Một cách tiếp cận triệt để hơn: chuyển đổi hầu hết giao thức thành mã hợp đồng
Một chiến lược đơn giản hóa Ethereum triệt để hơn sẽ là giữ nguyên giao thức nhưng chuyển phần lớn từ chức năng giao thức sang mã hợp đồng.
Phiên bản cực đoan nhất sẽ là biến Ethereum L1 về mặt kỹ thuật chỉ là chuỗi đèn hiệu và giới thiệu một máy ảo tối thiểu (chẳng hạn như RISC-V , Cairo hoặc thậm chí là một hệ thống bằng chứng chuyên dụng tối thiểu) cho phép những người khác tạo bản tổng hợp của riêng họ. EVM sau đó sẽ trở thành sản phẩm đầu tiên trong số các bản tổng hợp này. Trớ trêu thay, đây hoàn toàn là kết quả tương tự như đề xuất Môi trường điều hành 2019-20 , mặc dù SNARK khiến việc triển khai nó trên thực tế trở nên khả thi hơn.
Một cách tiếp cận khiêm tốn hơn sẽ là giữ nguyên mối quan hệ giữa chuỗi beacon và môi trường thực thi Ethereum hiện tại, nhưng thực hiện hoán đổi EVM tại chỗ. Chúng ta có thể chọn RISC-V, Cairo hoặc một máy ảo khác làm máy ảo Ethereum chính thức mới và sau đó buộc tất cả các hợp đồng EVM vào mã máy ảo mới để diễn giải logic mã gốc (thông qua biên dịch hoặc thông dịch). Về lý thuyết, điều này thậm chí có thể được thực hiện thông qua VM mục tiêu dưới dạng phiên bản của EOF.
