Một trong những thách thức của Ethereum là mặc định, bất kỳ giao thức chuỗi khối nào cũng tăng dần về kích thước và phức tạp theo thời gian. Điều này xảy ra ở hai nơi:
Để Ethereum tồn tại trong dài hạn, chúng ta cần một áp lực đối chống mạnh mẽ với cả hai xu hướng này, giảm độ phức tạp và đồng thời giảm độ phình to theo thời gian. Nhưng đồng thời, chúng ta cũng cần bảo tồn một trong những thuộc tính quan trọng làm cho các chuỗi khối trở nên xuất sắc: tính bền vững. Bạn có thể đặt một NFT, một ghi chú tình yêu trong dữ liệu giao dịch hoặc một hợp đồng thông minh chứa một triệu đô la trên chuỗi, đi vào một hang động trong mười năm, ra ngoài và thấy nó vẫn đang đợi bạn đọc và tương tác với nó. Đối với dapps để cảm thấy thoải mái khi hoàn toàn phi tập trung và loại bỏ các khóa nâng cấp của họ, họ cần tự tin rằng các phụ thuộc của họ sẽ không được nâng cấp theo cách gây hỏng chúng - đặc biệt là L1 chính nó.
The Purge, lộ trình năm 2023.
Cân bằng giữa hai nhu cầu này, và giảm thiểu hoặc đảo ngược sự phình to, phức tạp và phân rã trong khi vẫn duy trì tính liên tục, là hoàn toàn có thể nếu chúng ta đặt tâm trí vào nó. Các sinh vật sống có thể làm điều đó: trong khi hầu hết già đi theo thời gian, một số ít may mắn không. Even social systems can có tuổi thọ cực kỳ lâu dài. Trong một số trường hợp, Ethereum đã cho thấy những thành công: công việc chứng thực đã biến mất, mã lệnh SELFDESTRUCT đã phần lớn biến mất và các nút beacon chain đã lưu trữ dữ liệu cũ chỉ 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à tiến tới một kết quả cuối cùng ổn định trong dài hạn là thách thức cuối cùng của sự mở rộng dài hạn, bền vững kỹ thuật và thậm chí là an ninh của Ethereum.
Đến thời điểm viết bài này, một nút Ethereum đồng bộ đầy đủ yêu cầu khoảng 1.1 terabytekhông gian đĩa chokhách hàng thực hiệnVà một vài trăm gigabyte khác cho khách hàng thống nhất. Hầu hết đều là lịch sử: dữ liệu về các khối lịch sử, giao dịch và biên nhận, phần lớn trong số đó đã có một vài năm tuổi. Điều này có nghĩa là kích thước của một nút tiếp tục tăng lên hàng trăm gigabyte mỗi năm, ngay cả khi giới hạn gas không tăng lên.
Một tính năng giúp đơn giản hóa vấn đề lưu trữ lịch sử là vì mỗi khối chỉ định đến khối trước đó thông qua một liên kết băm (và khác cấu trúc) having consensus on the present is enough to have consensus on history. As long as the network has consensus on the latest block, any historical block or transaction or state (account balance, nonce, code, storage) can be provided by any single actor along with a Merkle proof, and the proof allows anyone else to verify its correctness. While consensus is an N/2-of-N trust model, history is a Mô hình tin cậy 1-trong-N.
Điều này mở ra rất nhiều tùy chọn về cách chúng ta có thể lưu trữ lịch sử. Một tùy chọn tự nhiên là một mạng nơi mỗi nút chỉ lưu trữ một phần trăm nhỏ của dữ liệu. Đây là cách mà các mạng torrent đã hoạt động trong nhiều thập kỷ: trong khi mạng tổng thể lưu trữ và phân phối hàng triệu tệp, mỗi người tham gia chỉ lưu trữ và phân phối một số ít tệp. Có thể ngược lại, phương pháp này thậm chí không nhất thiết làm giảm tính mạnh mẽ của dữ liệu. Nếu, bằng cách làm cho việc chạy nút trở nên phù hợp hơn, chúng ta có thể có được một mạng với 100.000 nút, trong đó mỗi nút lưu trữ 10% ngẫu nhiên của lịch sử, sau đó mỗi mảnh dữ liệu sẽ được nhân bản 10.000 lần - chính xác cùng một hệ số nhân bản như mạng 10.000 nút nơi mỗi nút lưu trữ tất cả.
Hôm nay, Ethereum đã bắt đầu di chuyển khỏi mô hình mọi nút lưu trữ tất cả lịch sử mãi mãi. Các khối đồng thuận (tức là các phần liên quan đến đồng thuận chứng cứ cổ phần) chỉ được lưu trữ trong khoảng ~6 tháng. Blobs chỉ được lưu trữ trong khoảng ~18 ngày.EIP-4444Mục tiêu của là giới thiệu một khoảng thời gian lưu trữ một năm cho các khối và biên lai lịch sử. Một mục tiêu dài hạn là có một khoảng thời gian cân đối (có thể là ~18 ngày) trong đó mỗi nút chịu trách nhiệm lưu trữ mọi thứ, sau đó có một mạng ngang hàng được tạo thành từ các nút Ethereum lưu trữ dữ liệu cũ hơn theo một cách phân tán.
Mã hóa đánh mất có thể được sử dụng để tăng tính ổn định trong khi vẫn giữ nguyên hệ số sao chép. Trong thực tế, các khối đã được mã hóa đánh mất để hỗ trợ lấy mẫu sẵn có dữ liệu. Giải pháp đơn giản nhất có thể là tái sử dụng mã hóa đánh mất này và đưa dữ liệu khối thực thi và đồng thuận vào các khối.
Công việc chính còn lại liên quan đến việc 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 cũng bao gồm sự nhất quán và blobs. Các giải pháp dễ nhất cho việc này là (i) đơn giản chỉ cần giới thiệu một thư viện torrent hiện có và (ii) một giải pháp gốc Ethereum được gọi là gate.mạng Cổng. Khi một trong hai yếu tố này được giới thiệu, chúng ta có thể bật EIP-4444. EIP-4444 không yêu cầu một hard fork, mặc dù nó đòi hỏi một phiên bản giao thức mạng mới. Vì lý do này, có giá trị trong việc kích hoạt nó cho tất cả các máy khách cùng một lúc, vì nếu không có nguy cơ máy khách gặp sự cố khi kết nối với các nút khác mong đợi tải xuống toàn bộ lịch sử nhưng thực sự không nhận được nó.
Sự đánh đổi chính là việc chúng ta cố gắng đến đâu để có sẵn dữ liệu lịch sử “cổ xưa”. Giải pháp dễ dàng nhất là đơn giản là ngừng lưu trữ lịch sử cổ xưa từ ngày mai, và phụ thuộc vào các nút lưu trữ cũ và các nhà cung cấp trung tâm khác nhau để sao chép. Điều này thì dễ dàng, nhưng làm suy yếu vị thế của Ethereum như một nơi lưu trữ hồ sơ vĩnh viễn. Con đường khó khăn, nhưng an toàn hơn, là xây dựng và tích hợp mạng torrent để lưu trữ lịch sử một cách phân tán. Ở đây, có hai chiều của “chúng ta cố gắng đến đâu”:
Một cách tiếp cận cực đoan dành cho (1) sẽ liên quan đếnchứng minh việc giữ chỗ: thực tế yêu cầu mỗi nhà xác minh chứng cứ cổ phần lưu trữ một phần trăm lịch sử và thường xuyên kiểm tra mật mã rằng họ đã làm như vậy. Một cách tiếp cận ôn hòa hơn là đặt tiêu chuẩn tự nguyện cho phần trăm lịch sử mà mỗi client lưu trữ.
Đối với (2), việc triển khai cơ bản chỉ liên quan đến việc thực hiện công việc đã được thực hiện ngày hôm nay: Portal đã lưu trữ các tệp ERA chứa toàn bộ lịch sử 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 điều này với quá 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 ngay cả khi không có nút lưu trữ nào khác tồn tại trực tuyến, bằng cách đồng bộ hóa trực tiếp từ mạng Cổng thông tin.
Giảm yêu cầu lưu trữ lịch sử có thể coi là quan trọng hơn cả trạng thái không có trạng thái nếu chúng ta muốn làm cho việc chạy hoặc quay một nút trở nên rất dễ dàng: trên tổng số 1,1 TB mà một nút cần có, khoảng 300 GB là trạng thái và khoảng 800 GB còn lại là lịch sử. Tầm nhìn về một nút Ethereum chạy trên đồng hồ thông minh và chỉ mất vài phút để cài đặt chỉ có thể đạt được nếu cả trạng thái không có trạng thái và EIP-4444 được thực thi.
Giới hạn lưu trữ lịch sử cũng làm cho việc hỗ trợ các phiên bản gần đây của giao thức trở nên khả thi hơn đối với các thiết lập mới của nút Ethereum, cho phép chúng trở nên đơn giản hơn rất nhiều. Ví dụ, nhiều dòng mã có thể được loại bỏ an toàn bây giờ khi các khe lưu trữ trống được tạo ra trong cuộc tấn công DoS năm 2016 đã được hoàn toàn điền đầy.Đã xóaBây giờ khi việc chuyển đổi sang chứng chỉ cổ phần đã trở thành quá khứ, khách hàng có thể an toàn xóa toàn bộ mã liên quan đến chứng chỉ công việc.
Dù chúng ta loại bỏ nhu cầu lưu trữ lịch sử cho các máy khách, yêu cầu lưu trữ của một máy khách sẽ tiếp tục tăng lên, khoảng 50GB mỗi năm, do sự tăng trưởng liên tục của trạng thái: số dư và số nonce của tài khoản, mã hợp đồng và lưu trữ hợp đồng. Người dùng có thể trả một lần để gánh nặng cho các máy khách Ethereum hiện tại và tương lai mãi mãi.
Trạng thái khó “hết hạn” hơn lịch sử, vì EVM được thiết kế căn bản dựa trên giả định rằng một khi một đối tượng trạng thái được tạo ra, nó sẽ 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. Nếu chúng ta giới thiệu tính vô trạng thái, có một lập luận rằng có lẽ vấn đề này không quá tồi tệ: chỉ có một lớp chuyên biệt của người xây dựng khối cần phải thực sự lưu trữ trạng thái, và tất cả các nút khác (thậm chídanh sách bao gồmsản xuất!) có thể chạy mà không cần trạng thái. Tuy nhiên, có một lập luận rằng chúng ta không muốn phụ thuộc quá nhiều vào trạng thái không có, và cuối cùng chúng ta có thể muốn hết hạn trạng thái để duy trì Ethereum phi tập trung.
Hôm 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 một tài khoản mới, (ii) tạo một tài khoản mới với mã, (iii) thiết lập một khe cắm lưu trữ chưa từng chạm đến trước đó), đối tượng trạng thái đó sẽ tồn tại mãi mãi. Điều chúng tôi muốn thay vào đó, là để các đối tượng tự động hết hạn theo thời gian. Thách thức chính là làm điều này một cách hoàn thành ba mục tiêu:
Dễ dàng giải quyết vấn đề mà không cần đạt được những mục tiêu này. Ví dụ, bạn có thể khiến mỗi đối tượng trạng thái cũng lưu trữ một bộ đếm cho ngày hết hạn của nó (có thể được mở rộng bằng cách đốt ETH, điều này có thể xảy ra tự động bất kỳ lúc nào nó được đọc hoặc viết), và có một quy trình lặp lại các trạng thái để loại bỏ các đối tượng trạng thái hết hạn. Tuy nhiên, điều này tạo ra tính toán phụ (và thậm chí là yêu cầu lưu trữ), và nó chắc chắn không đáp ứng yêu cầu thân thiện với người dùng. Nhà phát triển cũng sẽ gặp khó khăn khi suy luận về những trường hợp biên liên quan đến giá trị lưu trữ đôi khi được đặt lại thành không. Nếu bạn làm cho hợp đồng hẹn hết hạn trên toàn bộ hợp đồng, điều này làm cho cuộc sống kỹ thuật dễ dàng hơn cho nhà phát triển, nhưng nó làm cho kinh tế khó hơn: nhà phát triển sẽ phải suy nghĩ về cách “đi qua” chi phí lưu trữ đang diễn ra cho người dùng của họ.
Đây là những vấn đề mà cộng đồng phát triển lõi Ethereum đã đấu tranh suốt nhiều năm, bao gồm các đề xuất như “cho thuê blockchain“ và “regenesisCuối cùng, chúng tôi kết hợp những phần tốt nhất của các đề xuất và hội tụ vào hai danh mục của “các giải pháp tệ nhất nhất được biết”:
Các đề xuất hết hạn trạng thái một phần đều hoạt động theo cùng một nguyên lý. Chúng tôi chia trạng thái thành các phần. Mọi người lưu trữ vĩnh viễn “bản đồ cấp cao” của những phần trống hoặc không trống. Dữ liệu trong mỗi phần chỉ được lưu trữ nếu dữ liệu đó đã được truy cập gần đây. Có cơ chế “tái sinh” nơi nếu một phần không còn được lưu trữ, bất kỳ ai cũng có thể đưa dữ liệu đó trở lại bằng cách cung cấp chứng minh về dữ liệu đó là gì.
Những điểm khác biệt chính giữa những đề xuất này là: (i) làm thế nào chúng ta xác định “gần đây”, và (ii) làm thế nào chúng ta xác định “mảnh”? Một đề xuất cụ thể là EIP-7736, xây dựng trên thiết kế “stem-and-leaf” được giới thiệu cho cây Verkle (mặc dù tương thích với bất kỳ hình thức không có trạng thái nào, chẳng hạn như cây nhị phân). Trong thiết kế này, tiêu đề, mã và các khe lưu trữ kề nhau được lưu trữ dưới cùng một “stem”. Dữ liệu được lưu trữ dưới một stem có thể là tối đa 256 * 31 = 7.936 byte. Trong nhiều trường hợp, toàn bộ tiêu đề và mã, và nhiều khe lưu trữ quan trọng, của một tài khoản sẽ được lưu trữ dưới cùng một stem. Nếu dữ liệu dưới một stem cụ thể không được đọc hoặc ghi trong 6 tháng, dữ liệu sẽ không còn được lưu trữ nữa, thay vào đó chỉ lưu trữ một cam kết 32 byte (“stub”) cho dữ liệu. Các giao dịch trong tương lai truy cập vào dữ liệu đó sẽ cần “phục sinh” dữ liệu, với một chứng minh sẽ được kiểm tra so với stub.
Có các cách khác để triển khai một ý tưởng tương tự. Ví dụ, nếu mức độ chi tiết cấp tài khoản không đủ, chúng ta có thể tạo một kế hoạch trong đó mỗi phân phối 1/232 của cây được điều chỉnh bởi một cơ chế tương tự như cành lá.
Điều này phức tạp hơn vì các ưu đãi: kẻ tấn công có thể buộc khách hàng lưu trữ vĩnh viễn một lượng trạng thái rất lớn bằng cách đưa một lượng dữ liệu rất lớn vào một cây con duy nhất và gửi một giao dịch duy nhất mỗi năm để “làm mới cây”. Nếu bạn làm cho chi phí gia hạn tỷ lệ thuận (hoặc thời gian gia hạn tỷ lệ nghịch) với kích thước cây, thì ai đó có thể làm phiền người dùng khác bằng cách đưa một lượng dữ liệu rất lớn vào cùng một 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 động lực chi tiết dựa trên kích thước cây con: ví dụ, mỗi đối tượng trạng thái 216 = 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ách tiếp cận dựa trên STEM rất đơn giản và nó phù hợp với các ưu đãi, bởi vì thông thường tất cả dữ liệu trong STEM đều liên quan đến cùng một ứng dụng hoặc người dùng.
Loại bỏ bất kỳ sự phát triển trạng thái cố định nào, ngay cả các đoạn 32 byte? Điều này là một vấn đề khó khăn vì củaxung đột phục sinh: điều gì sẽ xảy ra nếu một đối tượng trạng thái bị xóa, 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ó? Với việc hết hạn một phần trạng thái, “sơ khai” ngăn không cho dữ liệu mới được tạo. Với việc hết hạn trạng thái đầy đủ, chúng tôi không thể đủ khả năng để lưu trữ ngay cả sơ khai.
Thiết kế dựa trên khoảng thời gian đị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 tôi có một danh sách các cây trạng thái liên tục phát triển và bất kỳ trạng thái nào được đọc hoặc viết đều được lưu trong cây trạng thái gần đây nhất. Một cây trạng thái trống mới được thêm một lần mỗi kỳ (nghĩ: 1 năm). Cây trạng thái cũ bị đóng băng rắn. Các nút đầy đủ dự kiến chỉ lưu trữ hai cây gần đây nhất. Nếu một đối tượng trạng thái không được chạm vào trong hai khoảng thời gian và do đó rơi vào một cây hết hạn, nó vẫn có thể được đọc hoặc ghi vào, nhưng giao dịch sẽ cần phải chứng minh bằng chứng Merkle cho nó - và một khi nó xảy ra, một bản sao sẽ được lưu lại trong cây mới nhất.
Một ý tưởng quan trọng để làm cho tất cả điều này thân thiện với người dùng và nhà phát triển là khái niệm về khoảng thời gian địa chỉ. Khoảng thời gian địa chỉ là một số là một phần của địa chỉ. Một quy tắc quan trọng là một địa chỉ có khoảng thời gian địa chỉ N chỉ có thể được đọc hoặc ghi vào trong hoặc sau giai đoạn N (nghĩa là khi danh sách cây trạng thái đạt đến độ dài N). Nếu bạn đang lưu một đối tượng trạng thái mới (ví dụ: hợp đồng mới hoặc số dư ERC20 mới), nếu bạn đảm bảo đặt đối tượng trạng thái vào hợp đồng có khoảng thời gian địa chỉ là N hoặc N-1, thì bạn có thể lưu nó ngay lập tức mà không cần cung cấp bằng chứng rằng không có gì ở đó trước đó. Mặt khác, bất kỳ bổ sung hoặc chỉnh sửa nào để nêu trong các khoảng thời gian địa chỉ cũ hơn đều yêu cầu bằng chứng.
Thiết kế này bảo tồn hầu hết các tính năng hiện tại của Ethereum, rất nhẹ về tính toán thêm, cho phép các ứng dụng được viết gần như như hôm nay (ERC20s sẽ cần phải viết lại, để đảm bảo rằng số dư của địa chỉ với chu kỳ địa chỉ N được lưu trữ trong một hợp đồng con mà chính nó có chu kỳ địa chỉ N), và giải quyết vấn đề “người dùng đi vào hang động trong năm 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 để vừa với chu kỳ địa chỉ.
Một đề xuất là giới thiệu một định dạng địa chỉ mới 32 byte, bao gồm một số phiên bản, một số giai đoạn địa chỉ và một hash mở rộng.
0x01000000000157aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF
Màu đỏ là một số phiên bản. Bốn số không màu cam ở đây được định nghĩa là không gian trống, có thể chứa một số shard trong tương lai. Màu xanh lá cây là một số kỳ hạn địa chỉ. Màu xanh dương là một hash 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 có được thiết kế xung quanh địa chỉ 20 byte, và thường sử dụng kỹ thuật đóng gói byte chặt chẽ mà rõ ràng cho rằng địa chỉ có đúng 20 byte.Một ý tưởng để giải quyết điều nàyliên quan đến một bản đồ dịch, trong đó hợp đồng theo kiểu cũ tương tác với địa chỉ theo kiểu mới sẽ nhìn thấy một băm 20 byte của địa chỉ theo kiểu mới. Tuy nhiên, có những khó khăn đáng kể liên quan đến việc làm cho điều này an toàn.
Một cách tiếp cận khác lại đi theo hướng ngược lại: chúng ta ngay lập tức cấm một số phạm vi con có kích thước 2128 (ví dụ tất cả địa chỉ bắt đầu bằng 0xffffffff), và sau đó sử dụng phạm vi đó để giới thiệu các địa chỉ với khoảng thời gian địa chỉ và băm 14 byte.
0xfffffff000169125d5dFcb7B8C2659029395bdF
Sự hy sinh quan trọng mà phương pháp này thực hiện, là nó giới thiệu rủi ro bảo mật cho các địa chỉ phi thực tế: địa chỉ giữ tài sản hoặc quyền hạn, nhưng mã của nó chưa được công bố trên chuỗi. Rủi ro liên quan đến việc ai đó tạo ra một địa chỉ khẳng định có một đoạn mã (chưa được công bố) nhưng cũng có một đoạn mã hợp lệ khác có cùng địa chỉ hash. Tính toán một va chạm như vậy yêu cầu 280hôm nay; sự rút ngắn không gian địa chỉ sẽ giảm số này xuống còn 2 rất dễ tiếp cận56hashes.
Lĩnh vực rủi ro chính, các địa chỉ phản chứng không phải là ví tiền được nắm giữ bởi một chủ sở hữu duy nhất, hiện nay là trường hợp hiếm gặp, nhưng có thể trở nên phổ biến hơn khi chúng ta bước vào một 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 thông thường mà điều này có thể gây ra vấn đề và đưa ra các giải pháp tạm thời hiệu quả.
Tôi nhìn thấy bốn con đường khả thi cho tương lai:
Một chức năng cần truy cập vào một số phần của trạng thái là sản xuất danh sách bao gồm, nhưng chúng ta có thể hoàn thành điều này một cách phi tập trung: mỗi người dùng chịu trách nhiệm duy trì phần của cây trạng thái chứa các tài khoản của riêng họ. Khi họ phát sóng một giao dịch, họ phát sóng nó với một chứng minh của các đối tượng trạng thái được truy cập trong quá trình xác minh (điều này hoạt động cho cả các tài khoản EOA và ERC-4337). Các trình xác minh không có trạng thái sau đó có thể kết hợp các chứng minh này thành một chứng minh cho toàn bộ danh sách bao gồm.
Một điểm quan trọng là những vấn đề khó khăn về mở rộng và thu hẹp không gian địa chỉ sẽ cuối cùng phải được giải quyết bất kể liệu các chương trình hết hạn trạng thái phụ thuộc vào các thay đổi định dạng địa chỉ có được triển khai hay không. Hôm nay, mất khoảng 280hashes để tạo ra một va chạm địa chỉ, một tải trọng tính toán mà hiện tại đã khả thi đối với các bên thực hiện tài nguyên rất tốt: một GPU có thể thực hiện khoảng 227hashes, vì vậy chạy trong một năm nó có thể tính toán 252vì vậy tất cả~2^30 GPUs trên thế giớicó thể tính toán va chạm trong khoảng 1/4 năm, và FPGAs và ASICs có thể tăng tốc điều này. Trong tương lai, các cuộc tấn công như vậy sẽ trở nên phổ biến hơn và hơn nữa. Do đó, chi phí thực tế của việc triển khai hết hạn trạng thái đầy đủ có thể không cao như vẻ ngoài, vì chúng ta phải giải quyết vấn đề địa chỉ khó khăn này bất kể.
Việc hết hạn trạng thái có thể làm cho các chuyển tiếp từ một định dạng cây trạng thái sang một định dạng khác dễ dàng hơn, vì sẽ không cần thiết phải có quy trình chuyển tiếp: bạn có thể đơn giản bắt đầu tạo cây mới bằng định dạng mới, và sau đó làm một hard fork để chuyển đổi các cây cũ hơn. Do đó, mặc dù việc hết hạn trạng thái là phức tạp, nhưng nó có lợi trong việc đơn giản hóa các khía cạnh khác của lộ trình.
Một trong những điều kiện tiên quyết quan trọng về an ninh, tính khả dụng vàtin cậy tính trung lập là sự đơn giản. Nếu một giao thức đẹp và đơn giản, nó sẽ làm giảm khả năng sẽ có lỗi. Nó làm tăng cơ hội mà các nhà phát triển mới sẽ có thể đến và làm việc với bất kỳ phần nào của nó. Nó có nhiều khả năng công bằng và dễ dàng hơn để bảo vệ chống lại các lợi ích đặc biệt. 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 chúng ta không muốn Ethereum đi vào một lỗ đen ngày càng phức tạp, chúng ta cần làm một trong hai điều: (i) ngừng thực hiện các thay đổi và hóa thạch 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. Một lộ trình trung gian, thực hiện ít thay đổi hơn đối với giao thức và cũng loại bỏ ít nhất một chút phức tạp theo thời gian, cũng có thể. Phần này sẽ nói về cách chúng ta có thể giảm hoặc loại bỏ sự phức tạp.
Không có một giải pháp duy nhất lớn nào có thể giảm độ phức tạp của giao thức; bản chất vốn đang gặp vấn đề là có quá nhiều giải pháp nhỏ.
Một ví dụ đã gần hoàn thành và có thể được coi là một bản thiết kế cho cách xử lý các ví dụ khác, làloại bỏ opcode SELFDESTRUCT. Mã opcode SELFDESTRUCT là duy nhất có thể sửa đổi một số lượng không giới hạn các khe lưu trữ trong một khối duy nhất, yêu cầu các client triển khai phức tạp hơn đáng kể để tránh các cuộc tấn công DoS. Mục đích ban đầu của mã opcode là cho phép làm sạch trạng thái tự nguyện, cho phép kích thước trạng thái giảm dần theo thời gian. Trong thực tế, rất ít người cuối cùng sử dụng nó. opcode đã bị giảm sức mạnhchỉ cho phép tài khoản tự hủy được tạo trong cùng một giao dịch trong Dencun hardfork. Điều này giải quyết vấn đề DoS và cho phép đơn giản hóa đáng kể trong mã khách hàng. Trong tương lai, có lẽ nên xóa opcode hoàn toàn.
Một số ví dụ chính về cơ hội đơn giản hóa giao thức mà cho đến nay đã được xác định bao gồm những điều sau. Đầu tiên, một số ví dụ nằm ngoài EVM; những ví dụ này tương đối không xâm phạm và do đó dễ dàng đạt được sự đồng thuận và triển khai trong một khoảng thời gian ngắn hơn.
Bây giờ, một số ví dụ nằm bên trong EVM:
Sự đánh đổi chính trong việc đơn giản hóa tính năng này là (i) mức độ chúng ta đơn giản hóa và tốc độ đó so với (ii) khả năng tương thích ngược. Giá trị của Ethereum như một chuỗi đến từ việc nó là một nền tảng mà bạn có thể triển khai một ứng dụng và tự tin rằng nó sẽ vẫn hoạt động trong nhiều năm tới. Đồng thời, có thể đưa quan niệm đó quá xa, và,để diễn giải lại William Jennings Bryan, “đóng đinh Ethereum trên cây thánh giá của tính tương thích ngược”. Nếu chỉ có hai ứng dụng trong Ethereum sử dụng một tính năng cụ thể và một ứng dụng không có người dùng trong nhiều năm và ứng dụng kia gần như không được sử dụng và bảo vệ tổng cộng 57 đô la, thì chúng ta chỉ cần loại bỏ tính năng đó và nếu cần, trả 57 đô la cho các nạn nhân từ túi của chúng ta.
Vấn đề xã hội rộng lớn hơn nằm ở việc tạo ra một đường ống tiêu chuẩn cho việc thực hiện các thay đổi phá vỡ tương thích ngược không khẩn cấp. Một cách tiếp cận là xem xét và mở rộng các tiền lệ hiện có, như quy trình SELFDESTRUCT. Đường ống trông có vẻ như sau:
Giữa bước 1 và bước 4 nên có một đường ống kéo dài nhiều năm, với thông tin rõ ràng về các mục đang ở bước nào. Đến thời điểm đó, có sự đánh đổi giữa việc đường ống loại bỏ tính năng mạnh mẽ và nhanh chóng hơn, so với việc thận trọng hơn và đầu tư nhiều tài nguyên hơn vào các lĩnh vực phát triển giao thức khác, nhưng chúng ta vẫn còn rất xa so với biên Pareto.
Một tập hợp lớn các thay đổi đã được đề xuất cho EVM là Định dạng Đối tượng EVM (EOF). EOF giới thiệu một số thay đổi lớn, như cấm quan sát gas, quan sát mã (tức là không CODECOPY), chỉ cho phép nhảy tĩnh. Mục tiêu là cho phép EVM được nâng cấp hơn, theo một cách có tính chất mạnh hơn, trong khi vẫn bảo tồn tính tương thích ngược (vì EVM trước EOF vẫn tồn tại).
Điều này có lợi thế là tạo ra một con đường tự nhiên để thêm các tính năng mới của EVM và khuyến khích di chuyển đến một EVM hạn chế hơn với các cam kết mạnh mẽ hơn. Nhược điểm của nó là tăng đáng kể độ phức tạp của giao thức, trừ khi chúng ta có thể tìm được cách để đánh dấu và loại bỏ EVM cũ. Một câu hỏi quan trọng 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 của EVM như một tổng thể?
Nhiều trong những đề xuất “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ụ từ trên:
Một chiến lược đơn giản hóa Ethereum cấp tiến hơn là giữ nguyên giao thức nhưng di chuyển một phần lớn của nó từ các tính năng giao thức sang mã hợp đồng.
Phiên bản cực đoan nhất của điều này sẽ là làm cho 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 (ví dụ: RISC-V, Cairo, hoặc thậm chí là một cái gì đó còn tối giản hơn được chuyên biệt cho việc chứng minh hệ thống) cho phép bất kỳ ai khác tạo ra rollup của riêng họ. EVM sau đó sẽ biến thành rollup đầu tiên của chúng. Điều này là một cách trớ trêu cũng chính là kết quả giống hệt như đề xuất môi trường thực thi từ 2019-20, tuy nhiên SNARKs làm cho việc triển khai trở nên đáng tin cậy hơn đáng kể.
Một phương pháp khá hợp lý là giữ nguyên mối quan hệ giữa chuỗi đèn hiệu và môi trường thực thi Ethereum hiện tại, nhưng thực hiện một hoán đổi trong chỗ của EVM. Chúng ta có thể chọn RISC-V, Cairo hoặc một VM khác làm “VM Ethereum chính thức” mới, sau đó buộc chuyển đổi tất cả các hợp đồng EVM sang mã mới-VM để giải thích logic của mã gốc (bằng cách biên dịch hoặc giải thích). Lý thuyết, điều này có thể được thực hiện với “VM đích” là một phiên bản của EOF.
Mời người khác bỏ phiếu
Một trong những thách thức của Ethereum là mặc định, bất kỳ giao thức chuỗi khối nào cũng tăng dần về kích thước và phức tạp theo thời gian. Điều này xảy ra ở hai nơi:
Để Ethereum tồn tại trong dài hạn, chúng ta cần một áp lực đối chống mạnh mẽ với cả hai xu hướng này, giảm độ phức tạp và đồng thời giảm độ phình to theo thời gian. Nhưng đồng thời, chúng ta cũng cần bảo tồn một trong những thuộc tính quan trọng làm cho các chuỗi khối trở nên xuất sắc: tính bền vững. Bạn có thể đặt một NFT, một ghi chú tình yêu trong dữ liệu giao dịch hoặc một hợp đồng thông minh chứa một triệu đô la trên chuỗi, đi vào một hang động trong mười năm, ra ngoài và thấy nó vẫn đang đợi bạn đọc và tương tác với nó. Đối với dapps để cảm thấy thoải mái khi hoàn toàn phi tập trung và loại bỏ các khóa nâng cấp của họ, họ cần tự tin rằng các phụ thuộc của họ sẽ không được nâng cấp theo cách gây hỏng chúng - đặc biệt là L1 chính nó.
The Purge, lộ trình năm 2023.
Cân bằng giữa hai nhu cầu này, và giảm thiểu hoặc đảo ngược sự phình to, phức tạp và phân rã trong khi vẫn duy trì tính liên tục, là hoàn toàn có thể nếu chúng ta đặt tâm trí vào nó. Các sinh vật sống có thể làm điều đó: trong khi hầu hết già đi theo thời gian, một số ít may mắn không. Even social systems can có tuổi thọ cực kỳ lâu dài. Trong một số trường hợp, Ethereum đã cho thấy những thành công: công việc chứng thực đã biến mất, mã lệnh SELFDESTRUCT đã phần lớn biến mất và các nút beacon chain đã lưu trữ dữ liệu cũ chỉ 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à tiến tới một kết quả cuối cùng ổn định trong dài hạn là thách thức cuối cùng của sự mở rộng dài hạn, bền vững kỹ thuật và thậm chí là an ninh của Ethereum.
Đến thời điểm viết bài này, một nút Ethereum đồng bộ đầy đủ yêu cầu khoảng 1.1 terabytekhông gian đĩa chokhách hàng thực hiệnVà một vài trăm gigabyte khác cho khách hàng thống nhất. Hầu hết đều là lịch sử: dữ liệu về các khối lịch sử, giao dịch và biên nhận, phần lớn trong số đó đã có một vài năm tuổi. Điều này có nghĩa là kích thước của một nút tiếp tục tăng lên hàng trăm gigabyte mỗi năm, ngay cả khi giới hạn gas không tăng lên.
Một tính năng giúp đơn giản hóa vấn đề lưu trữ lịch sử là vì mỗi khối chỉ định đến khối trước đó thông qua một liên kết băm (và khác cấu trúc) having consensus on the present is enough to have consensus on history. As long as the network has consensus on the latest block, any historical block or transaction or state (account balance, nonce, code, storage) can be provided by any single actor along with a Merkle proof, and the proof allows anyone else to verify its correctness. While consensus is an N/2-of-N trust model, history is a Mô hình tin cậy 1-trong-N.
Điều này mở ra rất nhiều tùy chọn về cách chúng ta có thể lưu trữ lịch sử. Một tùy chọn tự nhiên là một mạng nơi mỗi nút chỉ lưu trữ một phần trăm nhỏ của dữ liệu. Đây là cách mà các mạng torrent đã hoạt động trong nhiều thập kỷ: trong khi mạng tổng thể lưu trữ và phân phối hàng triệu tệp, mỗi người tham gia chỉ lưu trữ và phân phối một số ít tệp. Có thể ngược lại, phương pháp này thậm chí không nhất thiết làm giảm tính mạnh mẽ của dữ liệu. Nếu, bằng cách làm cho việc chạy nút trở nên phù hợp hơn, chúng ta có thể có được một mạng với 100.000 nút, trong đó mỗi nút lưu trữ 10% ngẫu nhiên của lịch sử, sau đó mỗi mảnh dữ liệu sẽ được nhân bản 10.000 lần - chính xác cùng một hệ số nhân bản như mạng 10.000 nút nơi mỗi nút lưu trữ tất cả.
Hôm nay, Ethereum đã bắt đầu di chuyển khỏi mô hình mọi nút lưu trữ tất cả lịch sử mãi mãi. Các khối đồng thuận (tức là các phần liên quan đến đồng thuận chứng cứ cổ phần) chỉ được lưu trữ trong khoảng ~6 tháng. Blobs chỉ được lưu trữ trong khoảng ~18 ngày.EIP-4444Mục tiêu của là giới thiệu một khoảng thời gian lưu trữ một năm cho các khối và biên lai lịch sử. Một mục tiêu dài hạn là có một khoảng thời gian cân đối (có thể là ~18 ngày) trong đó mỗi nút chịu trách nhiệm lưu trữ mọi thứ, sau đó có một mạng ngang hàng được tạo thành từ các nút Ethereum lưu trữ dữ liệu cũ hơn theo một cách phân tán.
Mã hóa đánh mất có thể được sử dụng để tăng tính ổn định trong khi vẫn giữ nguyên hệ số sao chép. Trong thực tế, các khối đã được mã hóa đánh mất để hỗ trợ lấy mẫu sẵn có dữ liệu. Giải pháp đơn giản nhất có thể là tái sử dụng mã hóa đánh mất này và đưa dữ liệu khối thực thi và đồng thuận vào các khối.
Công việc chính còn lại liên quan đến việc 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 cũng bao gồm sự nhất quán và blobs. Các giải pháp dễ nhất cho việc này là (i) đơn giản chỉ cần giới thiệu một thư viện torrent hiện có và (ii) một giải pháp gốc Ethereum được gọi là gate.mạng Cổng. Khi một trong hai yếu tố này được giới thiệu, chúng ta có thể bật EIP-4444. EIP-4444 không yêu cầu một hard fork, mặc dù nó đòi hỏi một phiên bản giao thức mạng mới. Vì lý do này, có giá trị trong việc kích hoạt nó cho tất cả các máy khách cùng một lúc, vì nếu không có nguy cơ máy khách gặp sự cố khi kết nối với các nút khác mong đợi tải xuống toàn bộ lịch sử nhưng thực sự không nhận được nó.
Sự đánh đổi chính là việc chúng ta cố gắng đến đâu để có sẵn dữ liệu lịch sử “cổ xưa”. Giải pháp dễ dàng nhất là đơn giản là ngừng lưu trữ lịch sử cổ xưa từ ngày mai, và phụ thuộc vào các nút lưu trữ cũ và các nhà cung cấp trung tâm khác nhau để sao chép. Điều này thì dễ dàng, nhưng làm suy yếu vị thế của Ethereum như một nơi lưu trữ hồ sơ vĩnh viễn. Con đường khó khăn, nhưng an toàn hơn, là xây dựng và tích hợp mạng torrent để lưu trữ lịch sử một cách phân tán. Ở đây, có hai chiều của “chúng ta cố gắng đến đâu”:
Một cách tiếp cận cực đoan dành cho (1) sẽ liên quan đếnchứng minh việc giữ chỗ: thực tế yêu cầu mỗi nhà xác minh chứng cứ cổ phần lưu trữ một phần trăm lịch sử và thường xuyên kiểm tra mật mã rằng họ đã làm như vậy. Một cách tiếp cận ôn hòa hơn là đặt tiêu chuẩn tự nguyện cho phần trăm lịch sử mà mỗi client lưu trữ.
Đối với (2), việc triển khai cơ bản chỉ liên quan đến việc thực hiện công việc đã được thực hiện ngày hôm nay: Portal đã lưu trữ các tệp ERA chứa toàn bộ lịch sử 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 điều này với quá 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 ngay cả khi không có nút lưu trữ nào khác tồn tại trực tuyến, bằng cách đồng bộ hóa trực tiếp từ mạng Cổng thông tin.
Giảm yêu cầu lưu trữ lịch sử có thể coi là quan trọng hơn cả trạng thái không có trạng thái nếu chúng ta muốn làm cho việc chạy hoặc quay một nút trở nên rất dễ dàng: trên tổng số 1,1 TB mà một nút cần có, khoảng 300 GB là trạng thái và khoảng 800 GB còn lại là lịch sử. Tầm nhìn về một nút Ethereum chạy trên đồng hồ thông minh và chỉ mất vài phút để cài đặt chỉ có thể đạt được nếu cả trạng thái không có trạng thái và EIP-4444 được thực thi.
Giới hạn lưu trữ lịch sử cũng làm cho việc hỗ trợ các phiên bản gần đây của giao thức trở nên khả thi hơn đối với các thiết lập mới của nút Ethereum, cho phép chúng trở nên đơn giản hơn rất nhiều. Ví dụ, nhiều dòng mã có thể được loại bỏ an toàn bây giờ khi các khe lưu trữ trống được tạo ra trong cuộc tấn công DoS năm 2016 đã được hoàn toàn điền đầy.Đã xóaBây giờ khi việc chuyển đổi sang chứng chỉ cổ phần đã trở thành quá khứ, khách hàng có thể an toàn xóa toàn bộ mã liên quan đến chứng chỉ công việc.
Dù chúng ta loại bỏ nhu cầu lưu trữ lịch sử cho các máy khách, yêu cầu lưu trữ của một máy khách sẽ tiếp tục tăng lên, khoảng 50GB mỗi năm, do sự tăng trưởng liên tục của trạng thái: số dư và số nonce của tài khoản, mã hợp đồng và lưu trữ hợp đồng. Người dùng có thể trả một lần để gánh nặng cho các máy khách Ethereum hiện tại và tương lai mãi mãi.
Trạng thái khó “hết hạn” hơn lịch sử, vì EVM được thiết kế căn bản dựa trên giả định rằng một khi một đối tượng trạng thái được tạo ra, nó sẽ 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. Nếu chúng ta giới thiệu tính vô trạng thái, có một lập luận rằng có lẽ vấn đề này không quá tồi tệ: chỉ có một lớp chuyên biệt của người xây dựng khối cần phải thực sự lưu trữ trạng thái, và tất cả các nút khác (thậm chídanh sách bao gồmsản xuất!) có thể chạy mà không cần trạng thái. Tuy nhiên, có một lập luận rằng chúng ta không muốn phụ thuộc quá nhiều vào trạng thái không có, và cuối cùng chúng ta có thể muốn hết hạn trạng thái để duy trì Ethereum phi tập trung.
Hôm 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 một tài khoản mới, (ii) tạo một tài khoản mới với mã, (iii) thiết lập một khe cắm lưu trữ chưa từng chạm đến trước đó), đối tượng trạng thái đó sẽ tồn tại mãi mãi. Điều chúng tôi muốn thay vào đó, là để các đối tượng tự động hết hạn theo thời gian. Thách thức chính là làm điều này một cách hoàn thành ba mục tiêu:
Dễ dàng giải quyết vấn đề mà không cần đạt được những mục tiêu này. Ví dụ, bạn có thể khiến mỗi đối tượng trạng thái cũng lưu trữ một bộ đếm cho ngày hết hạn của nó (có thể được mở rộng bằng cách đốt ETH, điều này có thể xảy ra tự động bất kỳ lúc nào nó được đọc hoặc viết), và có một quy trình lặp lại các trạng thái để loại bỏ các đối tượng trạng thái hết hạn. Tuy nhiên, điều này tạo ra tính toán phụ (và thậm chí là yêu cầu lưu trữ), và nó chắc chắn không đáp ứng yêu cầu thân thiện với người dùng. Nhà phát triển cũng sẽ gặp khó khăn khi suy luận về những trường hợp biên liên quan đến giá trị lưu trữ đôi khi được đặt lại thành không. Nếu bạn làm cho hợp đồng hẹn hết hạn trên toàn bộ hợp đồng, điều này làm cho cuộc sống kỹ thuật dễ dàng hơn cho nhà phát triển, nhưng nó làm cho kinh tế khó hơn: nhà phát triển sẽ phải suy nghĩ về cách “đi qua” chi phí lưu trữ đang diễn ra cho người dùng của họ.
Đây là những vấn đề mà cộng đồng phát triển lõi Ethereum đã đấu tranh suốt nhiều năm, bao gồm các đề xuất như “cho thuê blockchain“ và “regenesisCuối cùng, chúng tôi kết hợp những phần tốt nhất của các đề xuất và hội tụ vào hai danh mục của “các giải pháp tệ nhất nhất được biết”:
Các đề xuất hết hạn trạng thái một phần đều hoạt động theo cùng một nguyên lý. Chúng tôi chia trạng thái thành các phần. Mọi người lưu trữ vĩnh viễn “bản đồ cấp cao” của những phần trống hoặc không trống. Dữ liệu trong mỗi phần chỉ được lưu trữ nếu dữ liệu đó đã được truy cập gần đây. Có cơ chế “tái sinh” nơi nếu một phần không còn được lưu trữ, bất kỳ ai cũng có thể đưa dữ liệu đó trở lại bằng cách cung cấp chứng minh về dữ liệu đó là gì.
Những điểm khác biệt chính giữa những đề xuất này là: (i) làm thế nào chúng ta xác định “gần đây”, và (ii) làm thế nào chúng ta xác định “mảnh”? Một đề xuất cụ thể là EIP-7736, xây dựng trên thiết kế “stem-and-leaf” được giới thiệu cho cây Verkle (mặc dù tương thích với bất kỳ hình thức không có trạng thái nào, chẳng hạn như cây nhị phân). Trong thiết kế này, tiêu đề, mã và các khe lưu trữ kề nhau được lưu trữ dưới cùng một “stem”. Dữ liệu được lưu trữ dưới một stem có thể là tối đa 256 * 31 = 7.936 byte. Trong nhiều trường hợp, toàn bộ tiêu đề và mã, và nhiều khe lưu trữ quan trọng, của một tài khoản sẽ được lưu trữ dưới cùng một stem. Nếu dữ liệu dưới một stem cụ thể không được đọc hoặc ghi trong 6 tháng, dữ liệu sẽ không còn được lưu trữ nữa, thay vào đó chỉ lưu trữ một cam kết 32 byte (“stub”) cho dữ liệu. Các giao dịch trong tương lai truy cập vào dữ liệu đó sẽ cần “phục sinh” dữ liệu, với một chứng minh sẽ được kiểm tra so với stub.
Có các cách khác để triển khai một ý tưởng tương tự. Ví dụ, nếu mức độ chi tiết cấp tài khoản không đủ, chúng ta có thể tạo một kế hoạch trong đó mỗi phân phối 1/232 của cây được điều chỉnh bởi một cơ chế tương tự như cành lá.
Điều này phức tạp hơn vì các ưu đãi: kẻ tấn công có thể buộc khách hàng lưu trữ vĩnh viễn một lượng trạng thái rất lớn bằng cách đưa một lượng dữ liệu rất lớn vào một cây con duy nhất và gửi một giao dịch duy nhất mỗi năm để “làm mới cây”. Nếu bạn làm cho chi phí gia hạn tỷ lệ thuận (hoặc thời gian gia hạn tỷ lệ nghịch) với kích thước cây, thì ai đó có thể làm phiền người dùng khác bằng cách đưa một lượng dữ liệu rất lớn vào cùng một 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 động lực chi tiết dựa trên kích thước cây con: ví dụ, mỗi đối tượng trạng thái 216 = 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ách tiếp cận dựa trên STEM rất đơn giản và nó phù hợp với các ưu đãi, bởi vì thông thường tất cả dữ liệu trong STEM đều liên quan đến cùng một ứng dụng hoặc người dùng.
Loại bỏ bất kỳ sự phát triển trạng thái cố định nào, ngay cả các đoạn 32 byte? Điều này là một vấn đề khó khăn vì củaxung đột phục sinh: điều gì sẽ xảy ra nếu một đối tượng trạng thái bị xóa, 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ó? Với việc hết hạn một phần trạng thái, “sơ khai” ngăn không cho dữ liệu mới được tạo. Với việc hết hạn trạng thái đầy đủ, chúng tôi không thể đủ khả năng để lưu trữ ngay cả sơ khai.
Thiết kế dựa trên khoảng thời gian đị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 tôi có một danh sách các cây trạng thái liên tục phát triển và bất kỳ trạng thái nào được đọc hoặc viết đều được lưu trong cây trạng thái gần đây nhất. Một cây trạng thái trống mới được thêm một lần mỗi kỳ (nghĩ: 1 năm). Cây trạng thái cũ bị đóng băng rắn. Các nút đầy đủ dự kiến chỉ lưu trữ hai cây gần đây nhất. Nếu một đối tượng trạng thái không được chạm vào trong hai khoảng thời gian và do đó rơi vào một cây hết hạn, nó vẫn có thể được đọc hoặc ghi vào, nhưng giao dịch sẽ cần phải chứng minh bằng chứng Merkle cho nó - và một khi nó xảy ra, một bản sao sẽ được lưu lại trong cây mới nhất.
Một ý tưởng quan trọng để làm cho tất cả điều này thân thiện với người dùng và nhà phát triển là khái niệm về khoảng thời gian địa chỉ. Khoảng thời gian địa chỉ là một số là một phần của địa chỉ. Một quy tắc quan trọng là một địa chỉ có khoảng thời gian địa chỉ N chỉ có thể được đọc hoặc ghi vào trong hoặc sau giai đoạn N (nghĩa là khi danh sách cây trạng thái đạt đến độ dài N). Nếu bạn đang lưu một đối tượng trạng thái mới (ví dụ: hợp đồng mới hoặc số dư ERC20 mới), nếu bạn đảm bảo đặt đối tượng trạng thái vào hợp đồng có khoảng thời gian địa chỉ là N hoặc N-1, thì bạn có thể lưu nó ngay lập tức mà không cần cung cấp bằng chứng rằng không có gì ở đó trước đó. Mặt khác, bất kỳ bổ sung hoặc chỉnh sửa nào để nêu trong các khoảng thời gian địa chỉ cũ hơn đều yêu cầu bằng chứng.
Thiết kế này bảo tồn hầu hết các tính năng hiện tại của Ethereum, rất nhẹ về tính toán thêm, cho phép các ứng dụng được viết gần như như hôm nay (ERC20s sẽ cần phải viết lại, để đảm bảo rằng số dư của địa chỉ với chu kỳ địa chỉ N được lưu trữ trong một hợp đồng con mà chính nó có chu kỳ địa chỉ N), và giải quyết vấn đề “người dùng đi vào hang động trong năm 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 để vừa với chu kỳ địa chỉ.
Một đề xuất là giới thiệu một định dạng địa chỉ mới 32 byte, bao gồm một số phiên bản, một số giai đoạn địa chỉ và một hash mở rộng.
0x01000000000157aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF
Màu đỏ là một số phiên bản. Bốn số không màu cam ở đây được định nghĩa là không gian trống, có thể chứa một số shard trong tương lai. Màu xanh lá cây là một số kỳ hạn địa chỉ. Màu xanh dương là một hash 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 có được thiết kế xung quanh địa chỉ 20 byte, và thường sử dụng kỹ thuật đóng gói byte chặt chẽ mà rõ ràng cho rằng địa chỉ có đúng 20 byte.Một ý tưởng để giải quyết điều nàyliên quan đến một bản đồ dịch, trong đó hợp đồng theo kiểu cũ tương tác với địa chỉ theo kiểu mới sẽ nhìn thấy một băm 20 byte của địa chỉ theo kiểu mới. Tuy nhiên, có những khó khăn đáng kể liên quan đến việc làm cho điều này an toàn.
Một cách tiếp cận khác lại đi theo hướng ngược lại: chúng ta ngay lập tức cấm một số phạm vi con có kích thước 2128 (ví dụ tất cả địa chỉ bắt đầu bằng 0xffffffff), và sau đó sử dụng phạm vi đó để giới thiệu các địa chỉ với khoảng thời gian địa chỉ và băm 14 byte.
0xfffffff000169125d5dFcb7B8C2659029395bdF
Sự hy sinh quan trọng mà phương pháp này thực hiện, là nó giới thiệu rủi ro bảo mật cho các địa chỉ phi thực tế: địa chỉ giữ tài sản hoặc quyền hạn, nhưng mã của nó chưa được công bố trên chuỗi. Rủi ro liên quan đến việc ai đó tạo ra một địa chỉ khẳng định có một đoạn mã (chưa được công bố) nhưng cũng có một đoạn mã hợp lệ khác có cùng địa chỉ hash. Tính toán một va chạm như vậy yêu cầu 280hôm nay; sự rút ngắn không gian địa chỉ sẽ giảm số này xuống còn 2 rất dễ tiếp cận56hashes.
Lĩnh vực rủi ro chính, các địa chỉ phản chứng không phải là ví tiền được nắm giữ bởi một chủ sở hữu duy nhất, hiện nay là trường hợp hiếm gặp, nhưng có thể trở nên phổ biến hơn khi chúng ta bước vào một 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 thông thường mà điều này có thể gây ra vấn đề và đưa ra các giải pháp tạm thời hiệu quả.
Tôi nhìn thấy bốn con đường khả thi cho tương lai:
Một chức năng cần truy cập vào một số phần của trạng thái là sản xuất danh sách bao gồm, nhưng chúng ta có thể hoàn thành điều này một cách phi tập trung: mỗi người dùng chịu trách nhiệm duy trì phần của cây trạng thái chứa các tài khoản của riêng họ. Khi họ phát sóng một giao dịch, họ phát sóng nó với một chứng minh của các đối tượng trạng thái được truy cập trong quá trình xác minh (điều này hoạt động cho cả các tài khoản EOA và ERC-4337). Các trình xác minh không có trạng thái sau đó có thể kết hợp các chứng minh này thành một chứng minh cho toàn bộ danh sách bao gồm.
Một điểm quan trọng là những vấn đề khó khăn về mở rộng và thu hẹp không gian địa chỉ sẽ cuối cùng phải được giải quyết bất kể liệu các chương trình hết hạn trạng thái phụ thuộc vào các thay đổi định dạng địa chỉ có được triển khai hay không. Hôm nay, mất khoảng 280hashes để tạo ra một va chạm địa chỉ, một tải trọng tính toán mà hiện tại đã khả thi đối với các bên thực hiện tài nguyên rất tốt: một GPU có thể thực hiện khoảng 227hashes, vì vậy chạy trong một năm nó có thể tính toán 252vì vậy tất cả~2^30 GPUs trên thế giớicó thể tính toán va chạm trong khoảng 1/4 năm, và FPGAs và ASICs có thể tăng tốc điều này. Trong tương lai, các cuộc tấn công như vậy sẽ trở nên phổ biến hơn và hơn nữa. Do đó, chi phí thực tế của việc triển khai hết hạn trạng thái đầy đủ có thể không cao như vẻ ngoài, vì chúng ta phải giải quyết vấn đề địa chỉ khó khăn này bất kể.
Việc hết hạn trạng thái có thể làm cho các chuyển tiếp từ một định dạng cây trạng thái sang một định dạng khác dễ dàng hơn, vì sẽ không cần thiết phải có quy trình chuyển tiếp: bạn có thể đơn giản bắt đầu tạo cây mới bằng định dạng mới, và sau đó làm một hard fork để chuyển đổi các cây cũ hơn. Do đó, mặc dù việc hết hạn trạng thái là phức tạp, nhưng nó có lợi trong việc đơn giản hóa các khía cạnh khác của lộ trình.
Một trong những điều kiện tiên quyết quan trọng về an ninh, tính khả dụng vàtin cậy tính trung lập là sự đơn giản. Nếu một giao thức đẹp và đơn giản, nó sẽ làm giảm khả năng sẽ có lỗi. Nó làm tăng cơ hội mà các nhà phát triển mới sẽ có thể đến và làm việc với bất kỳ phần nào của nó. Nó có nhiều khả năng công bằng và dễ dàng hơn để bảo vệ chống lại các lợi ích đặc biệt. 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 chúng ta không muốn Ethereum đi vào một lỗ đen ngày càng phức tạp, chúng ta cần làm một trong hai điều: (i) ngừng thực hiện các thay đổi và hóa thạch 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. Một lộ trình trung gian, thực hiện ít thay đổi hơn đối với giao thức và cũng loại bỏ ít nhất một chút phức tạp theo thời gian, cũng có thể. Phần này sẽ nói về cách chúng ta có thể giảm hoặc loại bỏ sự phức tạp.
Không có một giải pháp duy nhất lớn nào có thể giảm độ phức tạp của giao thức; bản chất vốn đang gặp vấn đề là có quá nhiều giải pháp nhỏ.
Một ví dụ đã gần hoàn thành và có thể được coi là một bản thiết kế cho cách xử lý các ví dụ khác, làloại bỏ opcode SELFDESTRUCT. Mã opcode SELFDESTRUCT là duy nhất có thể sửa đổi một số lượng không giới hạn các khe lưu trữ trong một khối duy nhất, yêu cầu các client triển khai phức tạp hơn đáng kể để tránh các cuộc tấn công DoS. Mục đích ban đầu của mã opcode là cho phép làm sạch trạng thái tự nguyện, cho phép kích thước trạng thái giảm dần theo thời gian. Trong thực tế, rất ít người cuối cùng sử dụng nó. opcode đã bị giảm sức mạnhchỉ cho phép tài khoản tự hủy được tạo trong cùng một giao dịch trong Dencun hardfork. Điều này giải quyết vấn đề DoS và cho phép đơn giản hóa đáng kể trong mã khách hàng. Trong tương lai, có lẽ nên xóa opcode hoàn toàn.
Một số ví dụ chính về cơ hội đơn giản hóa giao thức mà cho đến nay đã được xác định bao gồm những điều sau. Đầu tiên, một số ví dụ nằm ngoài EVM; những ví dụ này tương đối không xâm phạm và do đó dễ dàng đạt được sự đồng thuận và triển khai trong một khoảng thời gian ngắn hơn.
Bây giờ, một số ví dụ nằm bên trong EVM:
Sự đánh đổi chính trong việc đơn giản hóa tính năng này là (i) mức độ chúng ta đơn giản hóa và tốc độ đó so với (ii) khả năng tương thích ngược. Giá trị của Ethereum như một chuỗi đến từ việc nó là một nền tảng mà bạn có thể triển khai một ứng dụng và tự tin rằng nó sẽ vẫn hoạt động trong nhiều năm tới. Đồng thời, có thể đưa quan niệm đó quá xa, và,để diễn giải lại William Jennings Bryan, “đóng đinh Ethereum trên cây thánh giá của tính tương thích ngược”. Nếu chỉ có hai ứng dụng trong Ethereum sử dụng một tính năng cụ thể và một ứng dụng không có người dùng trong nhiều năm và ứng dụng kia gần như không được sử dụng và bảo vệ tổng cộng 57 đô la, thì chúng ta chỉ cần loại bỏ tính năng đó và nếu cần, trả 57 đô la cho các nạn nhân từ túi của chúng ta.
Vấn đề xã hội rộng lớn hơn nằm ở việc tạo ra một đường ống tiêu chuẩn cho việc thực hiện các thay đổi phá vỡ tương thích ngược không khẩn cấp. Một cách tiếp cận là xem xét và mở rộng các tiền lệ hiện có, như quy trình SELFDESTRUCT. Đường ống trông có vẻ như sau:
Giữa bước 1 và bước 4 nên có một đường ống kéo dài nhiều năm, với thông tin rõ ràng về các mục đang ở bước nào. Đến thời điểm đó, có sự đánh đổi giữa việc đường ống loại bỏ tính năng mạnh mẽ và nhanh chóng hơn, so với việc thận trọng hơn và đầu tư nhiều tài nguyên hơn vào các lĩnh vực phát triển giao thức khác, nhưng chúng ta vẫn còn rất xa so với biên Pareto.
Một tập hợp lớn các thay đổi đã được đề xuất cho EVM là Định dạng Đối tượng EVM (EOF). EOF giới thiệu một số thay đổi lớn, như cấm quan sát gas, quan sát mã (tức là không CODECOPY), chỉ cho phép nhảy tĩnh. Mục tiêu là cho phép EVM được nâng cấp hơn, theo một cách có tính chất mạnh hơn, trong khi vẫn bảo tồn tính tương thích ngược (vì EVM trước EOF vẫn tồn tại).
Điều này có lợi thế là tạo ra một con đường tự nhiên để thêm các tính năng mới của EVM và khuyến khích di chuyển đến một EVM hạn chế hơn với các cam kết mạnh mẽ hơn. Nhược điểm của nó là tăng đáng kể độ phức tạp của giao thức, trừ khi chúng ta có thể tìm được cách để đánh dấu và loại bỏ EVM cũ. Một câu hỏi quan trọng 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 của EVM như một tổng thể?
Nhiều trong những đề xuất “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ụ từ trên:
Một chiến lược đơn giản hóa Ethereum cấp tiến hơn là giữ nguyên giao thức nhưng di chuyển một phần lớn của nó từ các tính năng giao thức sang mã hợp đồng.
Phiên bản cực đoan nhất của điều này sẽ là làm cho 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 (ví dụ: RISC-V, Cairo, hoặc thậm chí là một cái gì đó còn tối giản hơn được chuyên biệt cho việc chứng minh hệ thống) cho phép bất kỳ ai khác tạo ra rollup của riêng họ. EVM sau đó sẽ biến thành rollup đầu tiên của chúng. Điều này là một cách trớ trêu cũng chính là kết quả giống hệt như đề xuất môi trường thực thi từ 2019-20, tuy nhiên SNARKs làm cho việc triển khai trở nên đáng tin cậy hơn đáng kể.
Một phương pháp khá hợp lý là giữ nguyên mối quan hệ giữa chuỗi đèn hiệu và môi trường thực thi Ethereum hiện tại, nhưng thực hiện một hoán đổi trong chỗ của EVM. Chúng ta có thể chọn RISC-V, Cairo hoặc một VM khác làm “VM Ethereum chính thức” mới, sau đó buộc chuyển đổi tất cả các hợp đồng EVM sang mã mới-VM để giải thích logic của mã gốc (bằng cách biên dịch hoặc giải thích). Lý thuyết, điều này có thể được thực hiện với “VM đích” là một phiên bản của EOF.