Được viết bởi: Vitalik Buterin

Biên soạn bởi: Glendon, Techub News

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:

Để Ethereum bền vững về 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 bảo tồn một trong những đặc tính quan trọng tạo nên chuỗi khối: tính lâu dài. Bạn có thể đặt mộ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 một triệu đô la trên chuỗi, sau đó đi vào hang động mười năm và đi ra và thấy nó vẫn ở đó chờ bạn đọc và tương tác. Để DApp được phân cấp hoàn toàn và loại bỏ các khóa nâng cấp, họ cần tin tưởng 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 Lớp 1.

Cuộc thanh trừng, Lộ trình năm 2023

Việc cân bằng 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à suy thoái trong khi vẫn duy trì tính liên tục là điều hoàn toàn có thể thực hiện được nếu chúng ta tập trung vào nó. 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 về cơ bản đã biến mất 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 ổ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

Vấn đề gì đã được giải quyết?

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ố này là các hồ sơ 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 là từ nhiều năm trước. Điều này có nghĩa là kích thước nút sẽ 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à vì 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 hoặc 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 chứng Merkle cho phép bất kỳ ai khác xác minh tính chính xác của nó. Mặc dù sự đồng thuận là mô hình tin cậy N/2-of-N, lịch sử là mô hình tin cậy 1-of-N .

Điều này mở ra nhiều tùy chọn về cách chúng tôi lưu trữ dữ liệu 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 mạng torrent đã hoạt động trong nhiều thập kỷ: Trong khi mạng lưu trữ và phân phối tổng cộng 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ệ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 bằng cách làm cho các nút chạy rẻ hơn, chúng ta có thể có được một mạng gồm 100.000 nút, 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 - giống như một mạng gồm 10.000 nút . Hệ số sao chép hoàn toàn giống nhau, mọi nút đều 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à có một khoảng thời gian phối hợp (có thể ~ 18 ngày) trong đó mỗi nút chịu trách nhiệm lưu trữ mọi thứ, sau đó xây dựng mạng lưới các nút Ethereum ngang hàng để lưu trữ dữ liệu cũ theo cách phân tán. (Techub News lưu ý rằng Blob là một khái niệm lưu trữ dữ liệu được thiết kế để giảm chi phí giao dịch của các giải pháp mở rộng L2.)

Mã xóa có thể được sử dụng để cải thiện độ bền trong khi vẫn giữ nguyên hệ số sao chép. Trên thực tế, để hỗ trợ việc lấy mẫu dữ liệu sẵn có, các đốm màu đã sử dụng mã hóa xóa. Giải pháp đơn giản nhất có thể là sử dụng lại mã xóa nà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 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 là cả sự đồng thuận và các đốm màu. Giải pháp đơn giản nhất cho vấn đề này là (i) chỉ cần đưa vào thư viện torrent hiện có và (ii) giải pháp gốc Ethereum được gọi là " Portal Network ". Khi bất kỳ điều nào trong số này được giới thiệu, chúng tôi có thể kích hoạt 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 nó 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 thể kết nối với các nút khác muốn tải xuống toàn bộ lịch sử nhưng thực tế không thể tải xuống.

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ũ". 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. Một cách tiếp cận khó hơn nhưng an toàn hơn là trước tiên hãy 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, “mức độ nỗ lực của chúng tôi” có hai khía cạnh:

1. Làm cách nào để đả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?

2. Làm cách nào chúng ta có thể tích hợp sâu tính năng lưu trữ lịch sử vào giao thức?

Đối với (1), một trong những cách tiếp cận hoang tưởng nhất là sử dụng bằng chứng ký quỹ : yêu cầu hiệu quả mỗi trình xác thực bằng chứng cổ phần phải lưu trữ một tỷ lệ phần trăm nhất định của lịch sử 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 đã 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 thực sự sẽ yêu cầu 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ữ, ngay cả khi không có nút lưu trữ nào khác tồn tại trực tuyến, 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 vận hành.

Nó tương tác với các phần khác của lộ trình như thế nào?

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à bộ nhớ trạng thái và ~800 GB còn lại là Lịch sử kho. Tầm nhìn về các nút Ethereum chạy trên đồng hồ thông minh và chỉ mất vài phút để thiết lập chỉ có thể thành hiện thực nếu cả trạng thái không trạng thái và EIP-4444 đều được triển khai.

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ỉ hỗ trợ phiên bản mới nhất của giao thức dễ dàng hơn, khiến chúng trở nên đơn giản hơn. Ví dụ: nhiều dòng mã hiện có thể được xóa 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 bằng chứng cổ phần đã là lịch sử, khách hàng có thể xóa tất cả mã liên quan đến bằng chứng công việc một cách an toàn.

Nó giải quyết được vấn đề gì?

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 các 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ì thiết kế của EVM về cơ bản được xây dựng dựa trên giả định rằng một khi đối tượng trạng thái được tạo, nó sẽ tồn tại mãi mã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ố người cho rằng vấn đề này có thể không quá tệ nếu chúng ta áp dụng trạng thái không trạng thái: chỉ một lớp chuyên gia xây dựng khối mới thực sự cần lưu trữ trạng thái, trong khi tất cả các nút khác (thậm chí bao gồm 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 để các trạng thái hết hạn để giữ cho Ethereum được phân cấp.

Nó là gì và nó hoạt động như thế nào?

Bây giờ, khi bạn tạo một đối tượng trạng thái mới (điều này có thể được thực hiện 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 một khe lưu trữ chưa được chạm tới trước đó ), đối tượng trạng thái sẽ ở trạng thái này mãi mãi. 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. Để làm được điều này, thách thức chính là đạt được ba mục tiêu sau:

1. Hiệu quả: Không cần tính toán bổ sung nhiều để chạy quá trình hết hạn;

2. Thân thiện với người dùng: Nếu “ai đó đi vào hang và quay lại sau 5 năm”, họ sẽ không mất quyền truy cập vào các vị trí ETH, ERC20, NFT và CDP của mình.

3. 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.

Nếu không đáp ứng được những mục tiêu này, vấn đề sẽ được giải quyết dễ dàng. Ví dụ: người dùng có thể yêu cầu mỗi đối tượng trạng thái cũng lưu trữ một bộ đếm để biểu thị ngày hết hạn của nó (ngày hết hạn có thể được kéo dài bằng cách hủy ETH, điều này có thể xảy ra tự động khi đọc hoặc ghi) và có một vòng lặp "đi qua trạng thái". quá trình xóa các đối tượng trạng thái đã 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 người dùng đặt bộ hẹn giờ hết hạn trong toàn bộ hợp đồng, điều này về mặt kỹ thuật sẽ giúp công việc 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 tài chính: nhà phát triển phải xem xét 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 những đề xuất này và tập trung vào hai loại "giải pháp ít được biết đến nhất":

Trạng thái một phần hết hạn

Trạng thái một phần hết hạ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 "Bản đồ cấp cao nhất" với 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ữ khi nó được truy cập gần đây. Có một cơ chế "Phục sinh" trong đó nếu một khối không còn được lưu trữ, bất kỳ ai cũng có thể khôi phục dữ liệu bằng cách cung cấp bằng chứng về dữ liệu.

Sự khác biệt chính giữa các đề xuất này là: (i) chúng tôi định nghĩa "gần đây" như thế nào và (ii) chúng tôi định nghĩa "đoạn lớn" như thế nào? Một đề xuất cụ thể là EIP-7736 , được xây dựng dựa trên thiết kế "thân và lá" được giới thiệu cho cây Verkle (mặc dù tương thích với bất kỳ dạng cây không trạng thái nào, 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". Lượng dữ liệu tối đa được lưu trữ trong "gốc" là "256 * 31 = 7936 byte". Trong nhiều trường hợp, toàn bộ tiêu đề và mã của tài khoản cũng như nhiều khe lưu trữ chính sẽ được lưu trữ dưới cùng một "thân". Nếu dữ liệu trong một "sơ khai" nhất định không được đọc hoặc ghi trong vòng 6 tháng thì dữ liệu đó sẽ không còn được lưu trữ nữa mà chỉ lưu trữ cam kết 32 byte đối với dữ liệu ("sơ khai"). 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 xác minh đối với "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 sơ đồ trong đó mỗi phần "1/2^32" 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ể buộc khách hàng lưu trữ vĩnh viễn một lượng lớn trạng thái bằng cách đưa một lượng lớn dữ liệu vào một cây con và gửi một giao dịch mỗi năm để "cập nhật cây". Nếu bạn thực hiện chi phí cập nhật tỷ lệ thuận với kích thước "cây" (hoặc tỷ lệ nghịch với thời lượng cập nhật), thì ai đó có thể gây 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 một cây con với chính họ. Người dùng 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ách tiếp cận dựa trên gốc rất đơn giản và phù hợp với các biện pháp 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 bất kỳ sự tăng trưởng trạng thái cố định nào, ngay cả đối với các "sơ khai" 32 byte? Đây là một vấn đề khó khăn do Xung đột Phục sinh : nếu một đối tượng trạng thái bị xóa, việc thực thi EVM sau đó sẽ đặ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 sẽ quay lại và cố gắng khôi phục nó. Tôi có nên làm gì với nó không? "Sơ khai" ngăn dữ liệu mới được tạo khi một phần trạng thái hết hạn. Trong trường hợp hết hạn trạng thái, 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à cách tốt nhất để giải quyết vấn đề này. Thay vì sử dụng 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 khoảng thời gian (ví dụ: 1 năm). Cây trạng thái cũ sẽ vẫn ổn định. Một nút đầy đủ chỉ nên lưu trữ hai cây trạng thái 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 chu kỳ và do đó rơi vào cây trạng thái đã 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, bản sao sẽ lại được cập nhật trong cây trạng thái.

Ý tưởng chính giúp điều này trở nên thân thiện với 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à một đị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 người dùng 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ư ERC20 mới), nếu bạn đảm bảo đưa đố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 nó ngay lập tức mà không cung cấp Bằng chứng chứng minh trước đó không có gì cả. Mặt khác, bất kỳ bổ sung hoặc chỉnh sửa nào đối với trạng thái trong chu trình địa chỉ cũ đều cần có bằng chứng.

Thiết kế này giữ lại hầu hết các tính năng hiện tại của Ethereum với rất ít tính toán bổ sung, cho phép các ứng dụng được viết gần như hiện tại (ERC20 cần được viết lại để đảm bảo rằng số dư địa chỉ có chu kỳ địa chỉ N được lưu trữ trong các địa chỉ mà bản thân chúng có chu kỳ địa chỉ N phụ -hợp đồng), và giải quyết vấn đề "người dùng vào hang 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 để phù hợp với chu kỳ địa chỉ.

Phần 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à giá trị băm mở rộng.

Màu đỏ là số phiên bản. Bốn số 0 màu cam biểu thị 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 là sử dụng Bản đồ 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 điều này được an toàn.

Sự co lại của không gian địa chỉ

Một cách tiếp cận khác đi theo hướng ngược lại: chúng tôi vô hiệu hóa ngay lập tức 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 một địa chỉ có dấu chấm địa chỉ và 14 từ. của giá trị băm phần.

Một cách tiếp cận khác đi theo hướng ngược lại: chúng tôi vô hiệu hóa ngay lập tức 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 một địa chỉ có dấu chấm địa chỉ và 14 từ. của giá trị băm phần.

Sự hy sinh chính của phương pháp này là nó gây ra rủi ro bảo mật cho 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 là 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ó một đoạn mã hợp lệ khác có hàm băm trỏ đến cùng một địa chỉ. Việc tính toán một xung đột như vậy hiện yêu cầu hàm băm "2^80"; việc thu hẹp không gian địa chỉ sẽ giảm con số này xuống mức băm "2^56" dễ dàng truy cập.

Lĩnh vực rủi ro chính là các địa chỉ phản thực, tức là các ví không do một chủ sở hữu duy nhất nắm giữ, đây là một tình huống tương đối hiếm gặp hiện nay 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

Lý thuyết quản lý kích thước trạng thái Ethereum

Một số con đường có thể dẫn đến tình trạng không quốc tịch và hết hạn trạng thái

Đề 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:

1. Chúng tôi thực hiện tình trạng không quốc tịch và không bao giờ đưa ra quyết định hết hạn trạng thái. 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ỷ), nhưng chỉ cần được nắm giữ bởi một nhóm người dùng tương đối chuyên biệt: ngay cả trình xác thực PoS cũng không yêu cầu trạng thái.

Tôi nghĩ có bốn con đường khả thi cho tương lai:

1. Chúng tôi thực hiện tình trạng không quốc tịch và không bao giờ đưa ra quyết định hết hạn trạng thái. 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ỷ), nhưng chỉ cần được nắm giữ bởi một nhóm người dùng tương đối chuyên 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 đi 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.

2. 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 quy mô 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ự với các đề xuất hết hạn lịch sử liên quan đến mạng ngang hàng - cách chấp nhận tốc độ tăng trưởng thấp hơn nhiều nhưng vẫn khác 0 đối với việc lưu trữ lịch sử vĩnh viễn, vì 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.

3. Chúng tôi sử dụng phần mở rộng không gian địa chỉ để hết hạn trạng thái. Đ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ó.

4. Chúng tôi sử dụng tính năng thu hẹp không gian địa chỉ để hết hạn trạng thái. Đ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ác tình huống xuyên chuỗi) đều được xử lý.

Điểm quan trọng là dù 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ì các vấn đề khó khăn xung quanh việc mở rộng và thu hẹp không gian địa chỉ cuối cùng cũng phải được giải quyết. Hiện tại, cần khoảng "2 mũ 80" để tạo ra xung đột địa chỉ. Đối với những người tham gia có đủ tài nguyên, tải tính toán này đã khả thi: GPU có thể thực hiện khoảng "2 mũ 27" "Băm. giá trị hoạt động, do đó, một năm hoạt động có thể tính toán "2 lũy thừa 27" lần, do đó, tất cả các GPU trên thế giới khoảng "2 lũy thừa 30" có thể tính toán va chạm trong khoảng 1/4 năm, Trong khi FPGA và ASIC Quá trình này có thể được tăng tốc 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ế để đạt được trạng thái hết hạn hoàn toàn 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 thi 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 trạng thái mới bằng định dạng mới và sau đó dùng Hard Fork để 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ó giúp đơn giản hóa các khía cạnh khác của lộ trình.

Vấn đề gì đã được giải quyết?

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à sử dụng bất kỳ phần nào của nó. Nó có vẻ công bằng hơn và dễ bảo vệ hơn trước những 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 không muốn Ethereum rơi vào hố đ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ể thực hiện một con đường ở giữa, thực hiện ít thay đổi hơn đối với giao thức 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 chỉnh là loại bỏ opcode SELFDESTRUCT và nó có thể đóng vai trò là 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 để 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 dọn dẹp trạng thái tự nguyện, cho phép giảm kích thước trạng thái theo thời gian. Trong thực tế, ít người sử dụng nó. Trong hard fork Dencun, opcode này đã 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. Điều này giải quyết các vấn đề DoS và cho phép mã máy khách được đơn giản hóa đáng kể. Trong tương lai, việc loại bỏ hoàn toàn opcode này có thể là 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: Thứ nhất, một số ví dụ bên ngoài EVM tương đối không xâm phạm và do đó dễ dàng đạt được sự đồng thuận và triển khai hơn trong khung thời gian ngắn hơn.

Dưới đây là một số ví dụ từ bên trong EVM:

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ì?

Sự cân bằng chính trong việc đơn giản hóa tính năng như vậ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 nằm ở chỗ nó là nền tảng nơi người dùng có thể triển khai các ứ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, có thể lý tưởng này đã bị đẩy đi quá xa, “đóng đinh Ethereum vào khả năng tương thích ngược”, theo lời của William Jennings Bryan . 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 trong số chúng đã không có người dùng trong nhiều năm, gần như hoàn toàn không được sử dụng và đã nhận được tổng giá trị là 57 USD thì chúng ta nên xóa tính năng này, trả tiền để trả tiền túi nếu cần thiết, 57 đô la đã được trả cho nạn nhân.

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 phá vỡ khả năng tương thích ngược không khẩn cấp. Một cách để giải quyết 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ư quy trình SELFDESTRUCT. Quá trình này trông như thế này:

Cần có một quá trình kéo dài nhiều năm giữa các bước 1 và 4, với những 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ần phải có sự đánh đổi giữa "sức mạnh và tốc độ của quá trình loại bỏ tính năng" và "thận trọng hơn và đầu tư nhiều nguồn lực 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 cách xa "Pareto" biên cương” Còn xa lắm. (Techub News lưu ý, mặt trước Pareto ám chỉ tập hợp tất cả các lời giải tối ưu Pareto trong các bài toán tối ưu đa mục tiêu)

EOF

EOF

Một nhóm thay đổi chính được đề xuất cho EVM là Định dạng đối tượng EVM (EOF) . EOF giới thiệu một số thay đổi, chẳng hạn như vô hiệu hóa khả năng quan sát Gas, 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 để có 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).

Lợi ích của việc này là nó tạo ra một con đường tự nhiên để thêm các tính 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 để ngừng sử dụng và 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, điều chỉnh 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.

Bằng cách triển khai đầy đủ tính năng trừu tượng hóa tài khoản, chúng tôi có thể loại bỏ phần lớn logic xử lý giao dịch hiện có và chuyển nó thành một đoạn "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 dung 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 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 VM tối thiểu (chẳng hạn như RISC-V , Cairo hoặc một VM đơn giản hơn dành riêng cho hệ thống bằng chứng), cho phép những người khác tạo Rollup của riêng họ. EVM sau đó sẽ trở thành bản tổng hợp đầu tiên trong số này. Trớ trêu thay, đây lại là kết quả giống hệt với đề xuất về môi trường thực thi năm 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 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 (thông qua quá trình biên dịch hoặc giải thích) để diễn giải logic của mã gốc. Về lý thuyết, điều này thậm chí có thể được thực hiện bằng cách sử dụng "VM mục tiêu" làm phiên bản của EOF.