Xin chân thành cảm ơn Guillaume Ballet, Marius van der Wijden, Jialei Rong, CPerezz, Han, soispoke, Justin Drake, Maria Silva và Anders Elowsson vì những phản hồi và đánh giá.
Để mở rộng quy mô Ethereum trong năm năm tới, chúng ta cần mở rộng ba nguồn lực: thực thi (tính toán Máy ảo Ethereum (EVM) , xác minh chữ ký…), dữ liệu (người gửi giao dịch, người nhận, chữ ký, dữ liệu cuộc gọi…) và trạng thái (số dư tài khoản, mã, lưu trữ). Mục tiêu của chúng ta là mở rộng quy mô Ethereum lên khoảng 1000 lần. Nhưng có một sự bất đối xứng cơ bản giữa hai nguồn lực đầu tiên và nguồn lực thứ ba.
| Short hạn | Dài hạn | |
|---|---|---|
| Thực thi | ePBS, danh sách truy cập cấp khối (BAL) và định giá lại gas → tăng khoảng 10-30 lần | ZK-EVM (hầu hết các node có thể tránh hoàn toàn việc thực thi lại các khối) → Tăng khoảng 1000 lần Đối với một số loại tính toán cụ thể (chữ ký, SNARK/STARK), việc tổng hợp Ngoài chuỗi có thể giúp chúng ta đạt được hiệu quả gấp ~10000 lần. |
| Dữ liệu | Cải tiến p2p, gas đa chiều → tăng khoảng 10-20 lần | Khối dữ liệu trong các khối lớn + PeerDAS → 8 MB/giây ( tăng khoảng 500 lần ) |
| Tình trạng | Đồng bộ hóa với BAL, cải tiến p2p, cải tiến cơ sở dữ liệu → Tăng khoảng 5-30 lần | ? |
Trong Short hạn, chúng ta có thể tăng hiệu quả của cả ba nguồn lực. Nhưng để đạt được mức tăng gấp 1000 lần như mong muốn trong dài hạn, chúng ta cần những giải pháp thần kỳ. ZK-EVM là giải pháp thần kỳ cho việc thực thi. PeerDAS là giải pháp thần kỳ cho dữ liệu. Nhưng không có giải pháp thần kỳ nào cho trạng thái. Vậy chúng ta phải làm gì?
Bài viết này đề xuất một giải pháp đầy tham vọng: bên cạnh việc thực hiện các cải tiến từng bước cho trạng thái hiện tại (ví dụ: cây nhị phân, thời gian hết hạn của lá) và các cải tiến về giá cả như gas đa chiều, chúng tôi giới thiệu các dạng trạng thái mới (rẻ hơn nhiều, nhưng hạn chế hơn) song song với trạng thái hiện có .
Sự đánh đổi lớn là nếu chúng ta đặt mức "mục tiêu" cho sự tăng trưởng trạng thái, ví dụ như gấp 20 lần hiện nay, và hiệu năng gấp 1000 lần hiện nay, thì "giá tương đối" giữa hiệu năng và lưu trữ sẽ thay đổi đáng kể so với hiện tại. Việc tạo một khe lưu trữ mới có thể thực sự tốn kém hơn cả việc xác minh một STARK (!!). Có khả năng cả hai sẽ đều rẻ, nhưng mô hình tư duy về cái nào rẻ hơn sẽ thay đổi mạnh mẽ.
Như vậy, các nhà phát triển sẽ có sự lựa chọn: họ có thể chấp nhận phí giao dịch tương đối thấp nếu tiếp tục xây dựng ứng dụng theo cách hiện tại, hoặc phí giao dịch rất thấp nếu thiết kế lại ứng dụng để tận dụng các hình thức lưu trữ mới hơn. Đối với các trường hợp sử dụng phổ biến (ví dụ: số dư ERC20, NFT), sẽ có các quy trình làm việc được tiêu chuẩn hóa. Đối với các trường hợp sử dụng phức tạp hơn (ví dụ: DeFi), họ sẽ phải tự tìm ra các thủ thuật dành riêng cho ứng dụng để thực hiện.
Tại sao chúng ta không thể mở rộng quy mô trạng thái hiện tại lên hơn 10-20 lần?
Hiện nay, dung lượng bộ nhớ đang tăng với tốc độ khoảng 100 GB mỗi năm. Nếu tăng gấp 20 lần, con số này sẽ lên tới 2 TB mỗi năm. Sau 4 năm, điều này có nghĩa là dung lượng bộ nhớ sẽ đạt 8 TB.
Trạng thái này sẽ không cần phải được lưu trữ bởi các nút xác thực đầy đủ (vì chúng có thể nhận được mọi thứ cần thiết với ZK-EVM + PeerDAS), và thậm chí các nút FOCIL cũng không cần phải lưu trữ (VOPS nhỏ hơn đáng kể; nó sẽ dưới 1 TB ngay cả khi không có thay đổi, có thể dưới 512 hoặc thậm chí 256 GB, và nó có thể được tối ưu hóa hơn nữa). Nhưng nó sẽ cần thiết cho các nhà xây dựng (không chỉ các nhà xây dựng chuyên nghiệp, mà cả những "nhà xây dựng tại gia" địa phương sử dụng phần mềm "cơ bản").
Việc lưu trữ 8 TB trên ổ đĩa tự nó không khó. Chúng ta có thể cần một số thủ thuật để chỉ lưu trữ một phần dữ liệu "nóng" và tính thêm gas cho các phần khác, để chúng có thể được lưu trữ trong một tập tin phẳng thay vì cơ sở dữ liệu, nhưng nhìn chung, ổ đĩa 8 TB rất dễ kiếm. Có hai "phần khó": một phần ngắn hạn và một phần dài hạn:
- Short hạn: hiệu quả cơ sở dữ liệu . Các cơ sở dữ liệu hiện nay ở phía máy khách không được thiết kế để xử lý các trạng thái đa terabyte. Một vấn đề lớn hiện nay là việc ghi trạng thái cần thực hiện log(n) cập nhật vào cây, và mỗi cập nhật đó lại là log(n) thao tác trong cơ sở dữ liệu, và các yếu tố cụ thể sẽ tăng lên nhanh chóng khi n lớn hơn RAM nhiều lần. Đã có những thiết kế cơ sở dữ liệu giải quyết được vấn đề này; chúng chỉ cần được tinh chỉnh và áp dụng rộng rãi.
- Về lâu dài: đồng bộ hóa . Chúng tôi muốn việc xây dựng hệ thống trở nên Không cần cho phép, không cần xin phép và việc thiết lập cũng không quá phức tạp. Ngay cả với hiệu suất hoàn hảo, việc đồng bộ 8 TB cũng mất rất nhiều thời gian, và trong nhiều trường hợp còn gặp phải giới hạn băng thông hàng tháng.
Tất cả những điều này còn chưa kể đến các câu hỏi về việc bạn đồng bộ trạng thái từ đâu , ai vận hành các node RPC, và vô số các vấn đề khác. Ước tính sơ bộ cho thấy, cứ mỗi lần kích thước trạng thái tăng gấp đôi, số lượng tác nhân sẵn sàng thực hiện một số chức năng với trạng thái một cách vị tha (hoặc thậm chí có trả phí) sẽ giảm đi một nửa. Việc cải thiện hiệu quả cơ sở dữ liệu, sử dụng ổ cứng HDD và các tập tin phẳng thay vì ổ SSD và cơ sở dữ liệu phức tạp, ETC, chỉ giúp giải quyết một phần vấn đề này và hoàn toàn không giải quyết được vấn đề khác.
Không giống như dữ liệu và tính toán, đây không phải là những lĩnh vực mà chúng ta có thể nói "chúng ta dựa vào những người xây dựng chuyên nghiệp để đảm bảo quy mô, nếu tất cả họ biến mất, những người xây dựng thông thường chỉ cần xây những khối có kích thước bằng 10%". Để xây dựng một Block , bạn cần có toàn bộ trạng thái. Giảm Gas Limit không làm cho trạng thái nhỏ hơn.
Điều này có nghĩa là (i) chúng ta cần thận trọng hơn về trạng thái so với tính toán và dữ liệu, và (ii) nhiều kỹ thuật “phân mảnh” hoạt động hiệu quả đối với tính toán và dữ liệu nhưng lại không hiệu quả đối với việc lưu trữ trạng thái.
Vì sao tình trạng vô quốc tịch mạnh mẽ có lẽ vẫn chưa đủ.
Một chiến lược chính được đề xuất để giải quyết vấn đề này là trạng thái không xác định mạnh mẽ . Chúng tôi sẽ yêu cầu người dùng thực hiện giao dịch phải (i) chỉ định tài khoản và vị trí lưu trữ mà giao dịch của họ đọc và ghi, với quy tắc là bất kỳ nỗ lực đọc hoặc ghi nào bên ngoài tập hợp này sẽ thất bại, và (ii) cung cấp các nhánh Merkle chứng minh quyền truy cập trạng thái của họ.
Nếu chúng ta làm như vậy, chúng ta không còn cần các nhà phát triển lưu trữ toàn bộ trạng thái nữa. Thay vào đó, người dùng sẽ tự lưu trữ trạng thái (và các bằng chứng được cập nhật) liên quan đến việc sử dụng của họ, hoặc một mạng lưới phi tập trung sẽ lưu trữ trạng thái (ví dụ: mỗi nút sẽ giữ ngẫu nhiên 1/16 trạng thái).
Cách tiếp cận này có ba nhược điểm chính:
- Sự phụ thuộc vào cơ sở hạ tầng Ngoài chuỗi : trên thực tế, người dùng sẽ không thể lưu trữ trạng thái và bằng chứng liên quan đến việc sử dụng của riêng họ, bởi vì những gì "liên quan đến việc sử dụng của riêng họ" sẽ liên tục thay đổi, và bởi vì nhiều người dùng sẽ không trực tuyến mọi lúc để tải xuống các nhánh được cập nhật. Vì vậy, chúng ta cần một mạng lưới phi tập trung để lưu trữ và truy xuất trạng thái. Điều này cũng có những hệ quả về quyền riêng tư đối với người dùng.
- Không tương thích ngược : các ứng dụng mà việc truy cập vào bộ nhớ phụ thuộc vào quá trình thực thi giao dịch về cơ bản không tương thích với danh sách truy cập ràng buộc. Điều này có thể bao gồm sổ lệnh trên chuỗi, danh sách có thể thêm vào và nhiều loại cấu trúc khác. Đối với các ứng dụng này, người dùng sẽ cần mô phỏng cục bộ, tạo danh sách truy cập, và sau đó phần lớn thời gian giao dịch sẽ thất bại trên chuỗi (trong khi tiêu tốn gas) và họ sẽ phải thử lại nhiều lần.
- Chi phí băng thông : đối với mỗi khe lưu trữ được truy cập, các giao dịch sẽ cần cung cấp bằng chứng khoảng 1000 byte. Điều này làm tăng đáng kể kích thước giao dịch (ví dụ: một giao dịch chuyển Token ERC20 đơn giản có thể chiếm tới 4 kB dữ liệu chứng thực: một nhánh cho tài khoản người gửi, một nhánh cho mã thông báo ERC20, một nhánh cho số dư của người gửi, một nhánh cho số dư của người nhận, so với khoảng 200 byte hiện nay).
Một phiên bản yếu hơn của trạng thái phi tập trung mạnh mẽ là ý tưởng được gọi là “ trạng thái lạnh ”. Ý tưởng này cho rằng một số trạng thái (ví dụ: trạng thái chưa được truy cập trong hơn 1 năm) vẫn có thể truy cập được, nhưng với độ trễ không đồng bộ (thực tế, từ một giây đến một slot). Điều này cho phép các nhà phát triển chạy mà không cần bộ nhớ đó, vì bất cứ khi nào họ gặp yêu cầu đọc, họ sẽ gửi yêu cầu đến mạng phi tập trung để lấy dữ liệu.
Giải pháp này có thể hoạt động, nhưng nó dễ bị lỗi do phụ thuộc chặt chẽ vào cơ sở hạ tầng và gặp phải vấn đề không tương thích ngược tương tự. Có những giao dịch trường hợp xấu nhất với đồ thị phụ thuộc đa bước phức tạp đi qua các vùng trạng thái chờ khác nhau: gọi A, tùy thuộc vào đầu ra sẽ gọi đến một địa chỉ B khác, tùy thuộc vào đầu ra của cuộc gọi đó sẽ gọi đến một địa chỉ C khác…
Vì sao việc đảm bảo tính tương thích ngược của trạng thái hết hạn lại rất khó khăn?
Đã có một thập kỷ nỗ lực đề xuất cơ chế hết hạn trạng thái : các thiết kế trong đó trạng thái không được truy cập trong một thời gian dài sẽ tự động bị xóa khỏi trạng thái hoạt động, và người dùng muốn tiếp tục sử dụng trạng thái đó phải chủ động "khôi phục" nó.
Vấn đề không thể tránh khỏi mà tất cả các thiết kế này đều gặp phải là: khi bạn tạo ra một trạng thái mới, làm thế nào để chứng minh rằng trước đó chưa từng có gì ở đó ?
Nếu bạn tạo tài khoản tại địa chỉ X, bạn phải chứng minh rằng không có tài khoản nào khác được tạo tại địa chỉ X, không chỉ năm nay, hay năm trước, mà là tất cả các năm trước đó trong lịch sử của Ethereum.
Nếu chúng ta tạo một cây mới mỗi năm để thể hiện trạng thái được sửa đổi trong năm đó (" tái sinh lặp đi lặp lại"), thì việc tạo một tài khoản mới trong năm N sẽ yêu cầu N lần tra cứu.
Một ý tưởng được đưa ra để giảm thiểu vấn đề này là cơ chế thời kỳ địa chỉ : chúng tôi thêm một bộ quy tắc tạo tài khoản mới (“CREATE3”) cho phép bạn tạo một địa chỉ mà chỉ có thể chứng minh là hợp lệ khi được tạo trong năm >= N. Khi bạn tạo một tài khoản như vậy, sẽ không cần phải cung cấp bằng chứng cho bất kỳ năm nào < N, bởi vì việc tồn tại một tài khoản như vậy vào thời điểm đó là không thể.
Tuy nhiên, thiết kế này có những hạn chế lớn khi chúng ta bắt đầu cố gắng tích hợp nó vào thế giới Ethereum thực tế phức tạp. Cụ thể, hãy lưu ý rằng đối với mỗi tài khoản mới, chúng ta không chỉ cần tạo tài khoản mà còn cả các khe lưu trữ . Nếu bạn tạo một tài khoản X mới, thì bạn phải tạo số dư ERC20 của X cho mỗi Token mà bạn muốn nắm giữ. Điều này càng trở nên tồi tệ hơn vì các cơ chế chu kỳ địa chỉ không được "hiểu" bởi các ERC20 hiện có: mặc dù giao thức Ethereum có thể hiểu rằng một tài khoản X, với địa chỉ bằng cách nào đó mã hóa "2033" thông qua một cơ chế tạo địa chỉ mới, không thể được tạo trước năm 2033, nhưng khe lưu trữ cho số dư của X là sha256(…, X), đây là một cơ chế không rõ ràng mà giao thức không hiểu.
Chúng ta có thể giải quyết vấn đề này bằng một vài thủ thuật khéo léo. Một ý tưởng là thiết kế các token ERC20 mới theo cách tạo ra một hợp đồng con mới mỗi năm, lưu giữ số dư của các tài khoản liên kết với năm đó. Một ý tưởng khác là tạo ra một loại lưu trữ mới mà hợp đồng Token có thể sở hữu, nhưng "tồn tại cùng" với tài khoản của bạn, do đó có thể hết hạn và được khôi phục cùng với tài khoản của bạn. Nhưng cả hai ý tưởng này đều yêu cầu các hợp đồng Token ERC20 phải viết lại hoàn toàn logic của chúng, do đó chúng không tương thích ngược.
Mọi nỗ lực nhằm làm cho việc hết hạn trạng thái tương thích ngược dường như đều gặp phải những vấn đề tương tự, tất cả đều bắt nguồn từ vấn đề không có cách nào tốt để chứng minh sự không tồn tại. Ngoài ra, thật không may, không có cách nào để tạo ra một bản đồ "những địa chỉ / khe lưu trữ nào chưa được tạo trước đó" nhỏ hơn hoặc đơn giản hơn đáng kể so với trạng thái hiện tại. Một bản đồ {khóa 32 byte: {0,1}} có tất cả sự phức tạp trong việc triển khai của một bản đồ {khóa 32 byte: giá trị 32 byte}.
Những bài học rút ra từ các cuộc thám hiểm này
Chúng ta có thể tóm gọn những bài học tổng quan từ việc nghiên cứu về tình trạng không quốc gia mạnh và sự chấm dứt quốc gia thành hai “sự thật điển hình” lớn:
- Việc thay thế tất cả các truy cập trạng thái bằng các nhánh Merkle là quá tốn kém (về mặt băng thông), việc thay thế các truy cập trạng thái trong trường hợp ngoại lệ bằng các nhánh Merkle là chấp nhận được. "Thời hạn trạng thái" thực chất là một ví dụ điển hình cho trường hợp thứ hai: nếu ta giả định rằng, ví dụ, 90% các truy cập trạng thái chạm vào trạng thái có tuổi đời dưới sáu tháng và 10% chạm vào trạng thái cũ hơn, thì ta chỉ cần giữ trạng thái gần đây nhất trong nhóm "bắt buộc đối với người xây dựng" và yêu cầu chứng thực cho trạng thái cũ hơn, và thay vì phải trả chi phí gấp 20 lần, trung bình ta chỉ phải trả chi phí gấp 2 lần (cộng với giao dịch gốc).
Việc khám phá theo cách này dường như chắc chắn dẫn đến kết luận rằng chúng ta cần trạng thái phân cấp : sự phân biệt giữa trạng thái có giá trị cao mà chúng ta biết sẽ được truy cập thường xuyên, và trạng thái có giá trị thấp hơn mà chúng ta dự đoán sẽ được truy cập hiếm khi. Việc phân cấp có thể được thực hiện theo (i) cách thức truy cập gần đây, như trong các đề xuất về thời hạn trạng thái, hoặc (ii) thông qua các lớp trạng thái riêng biệt rõ ràng (ví dụ: VOPS là một phiên bản rất hạn chế của cách này). - Khả năng tương thích ngược rất khó khăn . Các tầng trạng thái thấp hơn không chỉ tốn kém hơn khi thao tác theo một số cách nhất định (đặc biệt là các lệnh gọi đồng bộ động), mà chúng hoàn toàn không thể được thao tác theo cách đó . Do đó, nếu chúng ta muốn tránh làm hỏng hoàn toàn các ứng dụng, lựa chọn duy nhất có thể là đẩy các ứng dụng hiện có lên tầng trạng thái tốn kém hơn và yêu cầu các nhà phát triển chủ động lựa chọn sử dụng các tầng trạng thái mới hơn, rẻ hơn.
Việc tạo ra các loại hình nhà nước mới với chi phí thấp hơn sẽ như thế nào?
Nếu trạng thái hiện tại không thể được làm cho hết hạn một cách tương thích ngược, giải pháp tự nhiên là chấp nhận sự thiếu tương thích ngược và thay vào đó áp dụng "giải pháp tạ đòn".
- Giữ nguyên trạng thái hiện tại gần như y hệt, nhưng cho phép nó trở nên tốn kém hơn một cách tương đối (ví dụ: việc thực thi có thể rẻ hơn 1000 lần, nhưng việc tạo trạng thái mới có thể chỉ rẻ hơn 20 lần).
- Tạo ra các loại trạng thái mới được thiết kế ngay từ đầu để thân thiện với khả năng mở rộng ở mức độ cực cao.
Khi thiết kế các loại trạng thái mới này, chúng ta nên ghi nhớ thực tế về loại đối tượng nào chiếm phần lớn trạng thái của Ethereum hiện nay: đó là số dư như token ERC20 và NFT.
Lưu trữ tạm thời
Một ý tưởng là tạo ra một loại bộ nhớ tạm thời mới có thời gian tồn tại trung bình. Ví dụ, chúng ta có thể có một cây mới được xóa sạch dữ liệu mỗi khi một chu kỳ mới (ví dụ: 1 tháng) bắt đầu.
Loại lưu trữ này sẽ lý tưởng để xử lý trạng thái tạm thời của các sự kiện trên chuỗi: đấu giá, bỏ phiếu quản trị, các sự kiện riêng lẻ trong trò chơi, cơ chế thách thức chống gian lận, ETC Chi phí gas của nó có thể được đặt ở mức khá thấp, cho phép nó mở rộng quy mô gấp 1000 lần cùng với quá trình thực thi.
Để triển khai hệ thống cân bằng kiểu ERC20 trên nền tảng trạng thái này, chắc chắn sẽ phải giải quyết một vấn đề: điều gì sẽ xảy ra nếu ai đó vào hang động hơn một tháng?
Một điểm hay của Use Case ERC20 là nó thân thiện với việc khôi phục không theo thứ tự. Ví dụ: nếu bạn nhận được 100 Dai vào năm 2025, sau đó quên mất, rồi nhận được 50 Dai vào cùng tài khoản đó năm 2027, và cuối cùng nhớ ra mình có số dư trước đó và khôi phục nó, bạn sẽ nhận lại được 150 Dai . Bạn thậm chí không cần cung cấp bất kỳ bằng chứng nào về việc có điều gì xảy ra với tài khoản của bạn vào năm 2026 hay không (nếu bạn cũng nhận được tiền vào thời điểm đó, bạn có thể cung cấp bằng chứng đó sau). Điều duy nhất chúng tôi muốn ngăn chặn là việc sử dụng cùng một trạng thái lịch sử để khôi phục số dư của bạn hai lần.
Đây là bản phác thảo về cách thức phục sinh có thể diễn ra:
- Là một phần của thiết kế cây, hãy lưu trữ trong mỗi nút tổng số lá "nằm dưới" nút đó. Điều này giúp việc xác minh đồng thời chỉ số của lá đó (theo thứ tự từ trái sang phải) trong cây trở nên khả thi trong quá trình chứng minh bất kỳ lá nào: bạn sẽ cộng tổng số của tất cả các nút chị em hướng sang trái trong quá trình chứng minh.
- Mỗi tháng, chúng ta sẽ lưu trữ một trường bit trạng thái vĩnh viễn, một Bit tương ứng với một giá trị trong cây tại thời điểm xóa. Trường bit này được khởi tạo bằng toàn bộ số không.
- Nếu trong tháng N, tài khoản X có quyền ghi vào ô Y, thì trong bất kỳ tháng nào > N, tài khoản đó có thể chỉnh sửa giá trị trường bit tương ứng của nó. Ngoài ra, bất kỳ ai cũng có thể cung cấp bằng chứng vào bất kỳ lúc nào.
- Theo mặc định, hợp đồng ERC20 sẽ lưu trữ số dư trong cây hiện tại, nhưng nó sẽ có tính năng khôi phục số dư, nhận đầu vào là một nhánh chứng minh trạng thái lịch sử của người gửi, và khôi phục số dư đồng thời đảo Bit từ 0 thành 1, để nó không thể được khôi phục lại lần nữa.
Hiện nay, dung lượng trạng thái tăng khoảng 100 GB mỗi năm. Nếu chúng ta mở rộng Ethereum lên 1000 lần, ta có thể hình dung mức tăng trưởng trạng thái tương tự sẽ được nhân lên 1000 lần, nhưng tất cả đều được lưu trữ trong các cây tạm thời. Điều này sẽ dẫn đến khoảng 8 TB trạng thái (giả sử thời hạn là 1 tháng), cộng thêm một lượng không đáng kể (1 Bit cho mỗi mục trạng thái 64 byte, vậy 8 TB * 1/8 / 64 = 16 GB mỗi tháng) dung lượng lưu trữ vĩnh viễn.
UTXO
Một cách khác là, chúng ta có thể đưa ý tưởng lưu trữ tạm thời đến cực điểm hợp lý: đặt thời gian hết hạn bằng không . Về cơ bản, các hợp đồng có thể tạo ra các bản ghi, và các bản ghi này sẽ được băm thành một cây trong Block đó, và ngay lập tức được đưa vào lịch sử. Đối với mỗi Block, bạn sẽ có một trường bit trong trạng thái để lưu trữ xem các bản ghi đã được "sử dụng" hay "chưa sử dụng", và đó sẽ là trạng thái vĩnh viễn, nhưng ngoài ra thì không có gì khác.
Về lý thuyết, UTXO có thể được xây dựng đơn giản bằng cách tái sử dụng cơ chế LOG hiện có và thêm cơ chế trường bit trạng thái lên trên. Nếu thực sự muốn, thậm chí có thể thực hiện như một Yêu cầu bình luận Ethereum (ERC) hoàn toàn nằm ngoài giao thức, mặc dù điều này có một số nhược điểm: một vài người dùng ngẫu nhiên sẽ phải chịu trách nhiệm trả gấp 256 lần so với những người khác để là người đầu tiên tạo ra một khe lưu trữ mới đại diện cho một phần trường bit có kích thước 256.
Các loại UTXO này có thể được xây dựng trên nền tảng ERC20, NFT và tất cả các loại tài sản trí tuệ khác.
Cũng có một phiên bản lai giữa hai ý tưởng này. Chúng ta sử dụng UTXO, nhưng cho phép truy cập trực tiếp vào cây dữ liệu của tháng trước đó từ trạng thái hệ thống, mà không cần chứng thực. Điều này giúp giảm tải băng thông (nhưng đổi lại dung lượng lưu trữ sẽ lớn hơn). Sự khác biệt chính giữa phương pháp này và ý tưởng lưu trữ tạm thời là ở đây, chỉ có một "giao diện" để xử lý các đối tượng đã được tạo trước đó (dưới dạng UTXO) thay vì hai giao diện (dưới dạng các khe lưu trữ của kỷ nguyên hiện tại và các UTXO của kỷ nguyên trước đó).
Cây lưu trữ không trạng thái mạnh
Chúng ta cũng có thể tạo một cây lưu trữ duy nhất, yêu cầu các nhánh Merkle để truy cập (hoặc cách khác, các nút phải lưu trữ N-8 cấp cao nhất của nó (tức là 1/256 kích thước), và các nút sẽ cung cấp các bằng chứng 256 byte). Cây lưu trữ mới này sẽ tồn tại song song với cây hiện có, vì vậy chúng ta sẽ có hai cây lưu trữ: một cây rẻ hơn yêu cầu bằng chứng và một cây đắt hơn không yêu cầu bằng chứng.
Tuy nhiên, theo quan điểm của tôi, phương án này kém hiệu quả hơn so với đề xuất lưu trữ tạm thời. Lý do là về lâu dài, nếu phần lớn cây đó là những dữ liệu rác bị lãng quên, và mọi người chỉ quan tâm đến một vài phần của nó, thì mạng lưới sẽ phải lưu trữ tệ nhất là toàn bộ cây bao gồm cả dữ liệu rác, hoặc tốt nhất là các nhánh Merkle cực dài chứng minh trạng thái hữu ích (vì mỗi đối tượng trạng thái hữu ích sẽ bị "bao quanh" bởi dữ liệu rác trong cây). Trong khi thiết kế hai cây chỉ cho phép hai "tầng" lưu trữ, thì thiết kế lưu trữ tạm thời tạo không gian cho cơ chế hết hạn trạng thái được xây dựng ở trên, cho phép phân tầng theo độ mới tồn tại trên nền tảng phân tầng kinh tế.
Hậu quả đối với trải nghiệm của nhà phát triển
Dưới đây là sơ đồ minh họa cách một số ứng dụng và quy trình làm việc sẽ hoạt động với kiến trúc phân tầng như vậy:
- Tài khoản người dùng (bao gồm cả trạng thái mới cho mỗi tài khoản liên quan đến AA gốc) sẽ được lưu trữ vĩnh viễn. Nhờ đó, tài khoản người dùng có thể được truy cập dễ dàng và tiết kiệm chi phí mọi lúc.
- Mã hợp đồng thông minh sẽ được lưu trữ vĩnh viễn.
- NFT, số dư Token ERC20, ETC sẽ được lưu trữ trong UTXO hoặc bộ nhớ tạm thời.
- Trạng thái liên quan đến các sự kiện ngắn hạn (ví dụ: đấu giá, trò chơi chống gian lận, trò chơi dự đoán, hành động quản trị) sẽ được lưu trữ tạm thời.
- Các hợp đồng DeFi cốt lõi sẽ được lưu trữ vĩnh viễn để tối đa hóa khả năng kết hợp.
- Các đơn vị hoạt động DeFi riêng lẻ (ví dụ: CDP) trong nhiều trường hợp sẽ nằm trong UTXO hoặc bộ nhớ tạm thời.
Ban đầu, các nhà phát triển có thể tiếp tục lưu trữ mọi thứ vào kho lưu trữ vĩnh viễn hiện có. Có lẽ, NFT và số dư Token ERC20 sẽ dễ dàng chuyển sang UTXO hoặc kho lưu trữ tạm thời nhất. Từ đó, hệ sinh thái sẽ được tối ưu hóa để sử dụng kho lưu trữ hiệu quả hơn theo thời gian.
Giả thuyết cơ bản ở đây là việc phát triển cho "lưu trữ vĩnh viễn kết hợp với UTXO" sẽ dễ dàng hơn nhiều so với "chỉ sử dụng UTXO". Một lý do chính khiến Ethereum thành công như một nền tảng dành cho nhà phát triển là vì tài khoản và khe lưu trữ đơn giản là thân thiện với nhà phát triển hơn nhiều so với UTXO. Nếu chúng ta có thể cung cấp các lớp trừu tượng thân thiện với nhà phát triển cho phép, ví dụ, 95% việc sử dụng trạng thái chuyển sang UTXO mà không gặp nhiều khó khăn, và giữ 5% còn lại dưới dạng lưu trữ vĩnh viễn (và cho phép các nhà phát triển, ngay cả những người bối rối về điều đó, vẫn có thể tiếp tục sử dụng lưu trữ vĩnh viễn cho mọi thứ với chi phí cao hơn), thì chúng ta có thể đạt được hầu hết lợi ích về khả năng mở rộng của UTXO và hầu hết lợi ích về tính thân thiện với nhà phát triển của tài khoản và khe lưu trữ kiểu Ethereum cùng một lúc.
