Giới thiệu

Những gì các chuỗi khối lưu trữ và tham chiếu trong quá trình xử lý giao dịch được gọi là trạng thái. Trên Ethereum, trạng thái là thuộc tính giúp đạt được sự đồng thuận của các nút. Mỗi nút đầy đủ cần lưu trữ và cập nhật trạng thái này trong mỗi chu kỳ các khối hợp lệ. Trạng thái, quan trọng như chúng là đối với các chuỗi khối, đi kèm với một hạn chế; chúng tăng theo thời gian. Chúng là một vấn đề lớn trong các chuỗi khối, như Bitcoin và Ethereum, vì việc tăng kích thước đến với việc tăng yêu cầu về phần cứng cho các nút. Ngưỡng không gian dần loại bỏ một số nút theo thời gian, dẫn đến tập trung. EIP-2935đề xuất mang lại sự không có trạng thái cho Ethereum, giảm bớt gánh nặng về kích thước cho các nút. EIP-2935 là một đề xuất cải tiến cố gắng thực hiện sự không có trạng thái bằng cách lưu trữ và phục vụ 8192 mã băm khối cuối cùng từ trạng thái cho việc thực thi không có trạng thái trong Ethereum.

Tóm tắt ngắn gọn về cấu trúc hiện tại của Ethereum

Khối

Các khối là các gói giao dịch có một tham chiếu (băm) của khối trước đó được bao gồm trong chuỗi. Các băm trong mỗi khối được tạo ra từ dữ liệu khối chính một cách mật mã. Sự bao gồm này liên kết các chuỗi với nhau bằng các băm, và việc gói giao dịch ngụ ý rằng tất cả các thành viên trong mạng đồng ý và đồng bộ trạng thái cùng một lúc. Hơn nữa, sự đồng ý về các khối được gói gửi cho biết Ethereum cập nhật trạng thái toàn cầu của nó trong mỗi thành viên trong mạng như một nút.

Alt: Thay đổi trạng thái trong Ethereum

Sau khi một khối mới được xử lý và phát sóng với một người xác minh trên mạng, các người tham gia còn lại sẽ thêm nó vào bộ nhớ lưu trữ của họ và cập nhật trạng thái toàn cầu của họ. Người xác minh của mỗi khối được chọn ngẫu nhiên bởi Tổ chức Tự trị Phi tập trung Ngẫu nhiên (RANDAO)Tham số. Cấu trúc khối được sắp xếp một cách chặt chẽ, và quy trình tạo khối và đạt được sự đồng thuận được quy định dưới giao thức chứng minh cổ phần của Ethereum.

Một khối chứa một số trường trong tiêu đề và thân. Ví dụ, tiêu đề khối bao gồm các trường slot, proposer_index, parent_root, state_root, và trường thân. Thân khối bao gồm randao_reveal, eth1_data, graffiti, proposer_slashings, attester_slashings, attestations, deposits, voluntary_exits, sync_aggregate, và execution_payload. Mỗi trường có các tham số khác nhau trong đó, và xử lý các nhu cầu khác nhau.

Ethereum’s 12 giâyGiai đoạn tạo khối, cũng gọi là “khe”, đến từ việc cho đủ thời gian cho các thành viên mạng đồng bộ hóa với các khối mới và đồng lòng với sự đồng thuận. Trong giai đoạn này:

1. Người đề xuất khối chọn ngẫu nhiên một người xác nhận,
2. Validator gói các giao dịch lại với nhau và thực hiện chúng để xác định trạng thái toàn cầu mới,
3. Họ bao gồm thông tin này trong một khối mới và phát sóng nó đến phần còn lại của bộ xác minh thông qua một giao thức tin đồn,
4. Các nhà xác thực khác thực hiện lại các giao dịch để đảm bảo tính hợp lệ và đồng ý với sự thay đổi trạng thái toàn cầu như một sự đồng thuận,
5. Nếu validator xác minh khối mới là hợp lệ, họ sẽ thêm nó vào bộ nhớ của mình.

Khối và tính kết thúc giao dịch có nghĩa là không thể thay đổi mà không cần thiết phải đốt ETH đáng kể trong một mạng phân tán. Ethereum có một phương pháp ‘khối kiểm tra’ để quản lý việc kết thúc. Khối đầu tiên trong mỗi kỷ nguyên được cho là là điểm kiểm tra của khe đó. Người xác minh bỏ phiếu cho giả định này để biến nó thành một điểm kiểm tra hợp lệ. Nếu hai phần ba tổng ETH đặt cược với các phiếu bầu của người xác minh bỏ phiếu bầu chọn một cặp điểm kiểm tra, các điểm kiểm tra được nâng cấp lên cấp độ đc chứng minh. Các điểm kiểm tra đã được chứng minh trước đó sẽ được nâng cấp sau khi điểm kiểm tra tiếp theo được nâng cấp và chúng trở thành kết thúc. Nếu một diễn viên độc hại muốn hoàn nguyên một khối đã kết thúc, họ cần cam kết mất ít nhất một phần ba tổng cung cấp ETH đặt cược. Mặc dù có một cơ chế gọi là rò rỉ không hoạt độngtồn tại để khôi phục tính xác định cuối cùng bằng cách áp đặt mức phạt lớn đối với quỹ xác nhận và cắt giảm phần thưởng của người xác nhận trong trường hợp thất bại vĩnh viễn của một số lượng lớn người xác nhận.

Khi xử lý khối, Ethereum áp dụng hàm băm để lấy dữ liệu của các khối và giảm nó thành chuỗi duy nhất. Trong hàm băm, mỗi đầu vào tạo ra một đầu ra duy nhất. Giá trị băm trong các khối là phần duy nhất không thể thay đổi. Nó có thể thay đổi với một phần ba ETH đặt cược tổng cộng bị đốt cháy. Tuy nhiên, số lượng này đến từ việc tính toán lại các giá trị băm của Merkle trie cho đến một điểm kiểm tra. Đầu ra của quá trình băm cho mỗi khối được trả về với tham số blockHash. Tham số blockHash bao gồm tất cả dữ liệu trong khối.

Các giá trị hash của các khối và các tham số cần thiết khác được lưu trữ trong cây Merkle. Ethereum sử dụng kiến trúc cây Merkle với các phiên bản khác nhau, chẳng hạn như Merkle Patricia Trie.

Cây Merkle và Cây Merkle Patricia

Cấu trúc Trie, đặc biệt là Merkle Tries, là cơ bản cho việc lưu trữ blockchain. Mà không có Merkle tries, blockchain trở thành các khối đơn lẻ khó xử lý mỗi lần. Với Merkle tries, hoặc tổng quát là kiến trúc trie, blockchain đạt được tính toàn vẹn với các phần cơ bản. Điều này giúp chúng trở thành các thành viên mạng với yêu cầu phần cứng thấp.

Cây thử Merkle là cách có cấu trúc để băm số lượng lớn các phần và chia chúng thành các phần. Với quá trình Merkelization, dữ liệu được tổ chức thành cặp; mỗi cặp được băm cùng nhau. Quá trình Merkelization lặp lại cho đến khi có được một gốc Merkle duy nhất.

Ethereum ưa thích Cây Merkle Patricia, một cấu trúc cây Merkle kép. Nó sử dụng Binary Tries cho việc xử lý dữ liệu cơ bản, như dữ liệu giao dịch, vì phương pháp này hiệu quả hơn trong những tình huống như vậy. Tuy nhiên, Ethereum sử dụng Cây Merkle Patricia phức tạp hơn trong các trường hợp phức tạp, như xử lý trạng thái.

Trong kịch bản lưu trữ dữ liệu của cây trie trạng thái, Ethereum tận dụng một bản đồ khóa-giá trị. Các khóa đại diện cho địa chỉ, và các giá trị đại diện cho các khai báo tài khoản. Cây trạng thái linh hoạt hơn so với cây nhị phân. Do đó, các tài khoản mới có thể được thêm vào thường xuyên, và các khóa có thể được thêm vào và xóa thường xuyên. Quá trình này cần một cấu trúc dữ liệu có thể cập nhật nhanh mà không cần tính toán lại toàn bộ bộ dữ liệu.

Cơ sở của cây trie chỉ phụ thuộc vào dữ liệu, không phụ thuộc vào thứ tự. Việc cập nhật dữ liệu theo các thứ tự khác nhau sẽ không thay đổi cơ sở chính nó.

Alt: Cây Trie Merkle Nhị phân

Ethereum sử dụng một phiên bản sửa đổi của Merkle Patricia Trie, có một số tính năng từ PATRICIA (Thuật toán Thực tế để Truy xuất Thông tin Được mã hóa bằng chữ số và chữ cái)và Merkle Trie với sự sửa đổi dọc theo nó. Kiến trúc này là xác định và có thể xác minh mật mã. Cách duy nhất để tạo ra một gốc trạng thái trong cấu trúc này là bằng cách tính toán từng phần trạng thái cá nhân. Hai trạng thái giống nhau có thể dễ dàng được chứng minh bằng cách so sánh băm gốc và các băm dẫn đến nó.

Cuối cùng, việc sửa đổi trạng thái với các giá trị khác nhau là không thể vì nó sẽ dẫn đến một bản gốc trạng thái khác. Tất cả cấu trúc trie trong lớp thực thi của Ethereum đều sử dụng Mạng trie Patricia Merkle. Mạng có ba trie: Trie Trạng thái, Trie Lưu trữ và Trie Giao dịch. Ngoài ra, mỗi block đều có Trie Biên nhận riêng của mình. Mặc dù Mạng trie Patricia Merkle hiệu quả ở nhiều cách, Ethereum được thúc đẩy để thay thế chúng bằng Mạng trie Verkle để đạt được sự không có trạng thái.

Alt: Cây Merkle Patricia Trie

Gas

Gas là thuộc tính cần thiết trong EVM để thực thi. Vì EVM sử dụng và cần tài nguyên tính toán để thực thi, việc trả lại những nỗ lực này được thanh toán bằng gas để đảm bảo an ninh của EVM. Phí gas được tính toán như là lượng gas cần thiết nhân với chi phí mỗi đơn vị. Đó là một giá trị động và phụ thuộc vào loại hoạt động.

Alt: https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf

EIP-1559Đã giới thiệu một số thay đổi đáng kể vào cơ chế phí giao dịch. Trả phí cho khí để bao gồm các giao dịch trong các khối đã hoạt động với một phương pháp giống như đấu giá trong quá khứ. Với EIP-1559, có một giới hạn tối thiểu được gọi là phí cơ bản và một mẹo được gọi là phí ưu tiên được giới thiệu. Các khối được đề xuất bắt đầu từ giao dịch có phí ưu tiên cao nhất. Sau quá trình khối, phí cơ bản bị đốt cháy, và phí ưu tiên được sử dụng để khuyến khích các nhà xác thực.

Trạng thái

Trạng thái blockchain có thể được xác định là một bộ dữ liệu (hoặc biến) mô tả một hệ thống cụ thể tại một thời điểm nhất định. Internet đã có trạng thái gần như từ đầu, nhưng nó được lưu trữ trên một máy chủ duy nhất. Với Web3, trạng thái toàn cầu được duy trì trên một mạng lưới mở và phân phối được bảo vệ thông qua các phương pháp phi tập trung được giới thiệu. Mọi người có thể xem và xác minh trạng thái của mạng phân phối vào bất kỳ thời điểm nào họ muốn.

Ethereum bao gồm các tài khoản, số dư, hợp đồng thông minh triển khai và lưu trữ liên quan trong trạng thái toàn cầu. Trạng thái Ethereum phát triển với sự bổ sung và thay đổi các tham số này. Sự phát triển trạng thái trở nên khó khăn khi chi phí phần cứng để lưu trữ một nút đầy đủ trở nên cấm kỵ. Trước những thách thức này, Vitalik Buterin giới thiệukhái niệm về Ethereum không có trạng thái vào năm 2017. Các phương pháp được đề xuất để sửa chữa sự phát triển trạng thái trong Ethereum bao gồm việc hết hạn dữ liệu và trạng thái.

Sự khác biệt giữa Hết hạn dữ liệu và Hết hạn trạng thái

Hết hạn dữ liệu

Dữ liệu hoặc lịch sử hết hạn có nghĩa là loại bỏ dữ liệu không cần thiết từ các máy khách sau một khoảng thời gian nhất định. Với “điểm kiểm tra tính chủ quan yếu thế”, các máy khách có thể tìm đường của mình trong việc đồng bộ hóa từ nguồn gốc và loại bỏ dữ liệu lịch sử không cần thiết.

Chủ quan đề cập đến các nút của mạng dựa vào thông tin xã hội để đạt được sự nhất trí về trạng thái hiện tại. Trong ngữ cảnh này, chủ quan yếu chỉ đến một chuỗi có thể tiến triển một cách khách quan với một số thông tin khởi đầu được khôi phục xã hội. Tuy nhiên, các điểm kiểm tra chủ quan yếu ngụ ý rằng tất cả các nút trên mạng chịu trách nhiệm cho sự nhất trí thuộc chuỗi cổ điển. Các điểm kiểm tra chủ quan yếu giúp Ethereum PoS có trạng thái gần đây (điểm kiểm tra chủ quan yếu) từ một nguồn tin cậy để đồng bộ từ.

EIP-4444cung cấp con đường thực tế đến@hBXHLw_9Qq2va4pRtI4bIA/ryzBaf7fJx?ref=ghost-2077.arvensis.systems”>dữ liệu hết hạn thông qua tính chủ quan yếu. Đề xuất không nhằm thay đổi cách các nút Ethereum xử lý dữ liệu trạng thái; thay vào đó, nó điều chỉnh quyền truy cập vào dữ liệu lịch sử.

Hết hạn trạng thái

State Expiry cố gắng loại bỏ trạng thái từ các nút cá nhân nếu nó chưa được truy cập gần đây. Việc hết hạn có thể được thực hiện bằng cách kết thúc là một yếu tố của tiền thuê hoặc thời gian. Hết hạn bằng tiền thuê có nghĩa là áp đặt một khoản phụ phí cho các tài khoản để lưu trữ trạng thái. Ngược lại, hết hạn theo thời gian có nghĩa là làm cho các tài khoản trở thành không hoạt động nếu chúng vẫn không hoạt động trong một khoảng thời gian nhất định.

Cả Dữ liệu lẫn Trạng thái Hết hạn đều là các lĩnh vực nghiên cứu mở. Các phương pháp hiện tại để đạt được các trạng thái được đề xuất này liên quan đến việc truyền qua các mạng/cung cấp trung tâm. Đến nay, tình trạng không có trạng thái mạnh mẽ và trạng thái hết hạn đã được đạt được một cách một phần trên Ethereum.

Stateless Ethereum

Giới thiệu về Tính vô trạng thái và Ethereum vô trạng thái

Ethereum Stateless giới thiệu các khái niệm mới vào giao thức cốt lõi. Lý tưởng, sự không có trạng thái không ám chỉ rằng không có trạng thái tồn tại. Thay vào đó, nó có nghĩa là khách hàng có thể chọn trạng thái họ muốn duy trì. Khi khách hàng nhận được các khối đã được xác minh, họ cũng nhận được bằng chứng tương ứng cho khối đó. Bằng chứng cho mỗi khối bao gồm tất cả dữ liệu cần thiết để thực thi các giao dịch chứa trong khối đó.

EIP-161đã giới thiệu phương pháp giảm trạng thái đầu tiên. Ethereum đã bị tấn công DoS (Từ chối Dịch vụ), và lỗ hổng này cho phép tạo các tài khoản trống mà tăng trạng thái toàn cầu của Ethereum. EIP-161 đề xuất loại bỏ các tài khoản trống có giá trị không (0) tại nonce của chúng mà đến từ cuộc tấn công này, với chi phí thấp. Đề xuất đã được thực hiện, dẫn đến một sự quay trở lại trạng thái.

Một nỗ lực khác hướng đến trạng thái khôngEIP-4788. Đề xuất này nhằm tiết lộ nguồn gốc của các khối beacon chain trong EVM. Tương tự như cách tiếp cận của Cầu Eth1-Eth2Kết nối chuỗi Beacon (lớp đồng thuận) và lớp thực thi, đề xuất này cho phép truy cập tối thiểu tin cậy giữa EVM và lớp đồng thuận.

Bởi vì mỗi khối thực thi chứa gốc của khối pha mẹ, các sự kiện khe trống bị bỏ lỡ sẽ không cần thay đổi gốc khối trước đó. Do đó, các điều kiện tiên quyết của quá trình thực thi thu hẹp lại thành việc dành một không gian nhỏ cho một oracal tối giản tin cậy trong mỗi khối thực thi. Đề xuất cho rằng nên lưu trữ một lịch sử nhỏ của các gốc khối trong một hợp đồng gốc để cải thiện hiệu suất của oracal.

Trong Ethereum, việc không có trạng thái có thể xảy ra dưới dạng không mạnh hoặc mạnh.

Trạng thái yếu

Trạng thái yếu không loại bỏ nhu cầu lưu trữ trạng thái trong tất cả các nút. Thay vào đó, nó khác biệt ở chỗ các nút xác minh các thay đổi đối với trạng thái Ethereum. Nó đặt trách nhiệm lưu trữ trạng thái cho người đề xuất khối và yêu cầu các nút khác xác minh các khối mà không lưu trữ dữ liệu trạng thái đầy đủ.

Người đề xuất khối cần lưu trữ dữ liệu trạng thái đầy đủ. Tuy nhiên, các khách hàng xác minh không cần phải lưu trữ dữ liệu trạng thái trên mạng. Thay vào đó, họ có thể lưu trữ gốc trạng thái (một băm của toàn bộ trạng thái). Sự thiếu trạng thái yếu đòi hỏi Sự Tách Biệt Giữa Người Đề Xuất và Người Xây Dựng (PBS)vàVerkle cố gắngthực hiện.

Người đề xuất tạo ra các nhân chứng bằng cách sử dụng dữ liệu trạng thái để chứng minh sự thay đổi trạng thái, và người xác thực xác minh các bằng chứng so với hàm băm gốc trạng thái.

Trạng thái mạnh mẽ không có

Tính trạng không có trạng thái mạnh mẽ loại bỏ nhu cầu lưu trữ dữ liệu trạng thái của bất kỳ nút nào. Nó hoạt động bằng cách tích hợp các giao dịch được gửi và các nhân chứng được tổng hợp bởi người đề xuất khối. Người đề xuất khối chỉ lưu trữ trạng thái duy nhất mà họ đang làm việc, tạo ra nhân chứng cho các tài khoản liên quan. Đề xuất vẫn cần phát triển thêm và bao gồm yêu cầu như Danh sách truy cậphoặc EIP-2930.

Tuy nhiên, một số thay đổi và thuộc tính có thể được sử dụng để đạt được trạng thái không có trạng thái. EIP-2935 đề xuất cung cấp các băm khối lịch sử từ trạng thái để cho phép thực thi không có trạng thái.

Giới thiệu về EIP-2935

EIP-2935 nhằm lưu trữ các hash khối lịch sử trong trạng thái blockchain trong các khe lưu trữ đặc biệt được gọi là HISTORY_STORAGE_ADDRESS. Quá trình này sẽ cho phép thực thi không trạng thái bằng cách tạo điều kiện dễ dàng truy cập vào thông tin lịch sử cần thiết trong các máy khách không trạng thái.

EIP-2935 đề xuất lưu trữ 8192 hash khối lịch sử cuối cùng trong một hợp đồng hệ thống để sử dụng như một phần của logic xử lý khối. Vấn đề mà đề xuất này cố gắng giải quyết là giả định của EVM rằng khách hàng có hash khối gần đây. Phương pháp dựa trên giả định này không áp dụng cho tương lai Ethereum và đặc biệt là các khách hàng không trạng thái.

Bao gồm các mã băm khối trước đó trong trạng thái sẽ cho phép gói các mã băm này với các hàm băm trong tầm nhìn của một nhân chứng. Sau đó, một nhân chứng sẽ được cung cấp cho khách hàng không trạng thái để xác minh việc thực thi và đạt được việc thực thi không trạng thái. Đề xuất này được gọi là đặc chủng trước Verkle vì nó có thể được triển khai trước khi thích nghi với Verkle tries trong giao thức cốt lõi, và nó hỗ trợ việc không trạng thái một phần.

Mở rộng phạm vi các khối mà blockHash phục vụ lên 8192 khối sẽ cho phép chuyển đổi mềm sang các phương thức thực thi. Rollups có thể hưởng lợi từ cửa sổ lịch sử dài hơn này bằng cách truy vấn trực tiếp hợp đồng này vì dữ liệu blockHash được lưu trữ trong hợp đồng này. Bên cạnh đó, KCN sinh thái này sẽ tạo điều kiện thuận lợi cho việc xác nhận các bằng chứng liên quan đến khối 8192 của HISTORY_SERVE_WINDOW so với trạng thái hiện tại.

Hiểu về EIP-2935

EIP-2935 cho phép các máy khách Ethereum, đặc biệt là các máy không trạng thái, dễ dàng truy cập các mã băm khối gần đây. Để làm việc này, nó giới thiệu bốn tham số mới:

• BLOCKHASH_SERVE_WINDOW: Thông báo cho khách hàng biết họ nên giữ bao nhiêu mã hash khối quá khứ. Giá trị mặc định là 256.
• LỊCH_SỬ_CỬA_SỔ_PHỤC_VỤ: Tham số này xác định bao nhiêu khối hash được lưu trữ. Giá trị mặc định là 8191.
• SYSTEM_ADDRESS: Một địa chỉ đặc biệt (ban đầu được giới thiệu trong EIP-4788) hoạt động như “người gọi” để viết các băm khối vào bộ nhớ.
• ĐỊA_CHỈ_LƯU_TRỮ_LỊCH_SỬ: Địa chỉ hợp đồng nơi các hash khối này được lưu trữ.

Các thông số của đề xuất hướng dẫn các khối hash cuối cùng của cửa sổ phục vụ LỊCH_SỬ được lưu trữ trong một bộ đệm vòng có độ dài là LỊCH_SỬ_PHỤC_VỤ.

Vòng lặp đệm

EIP-2935 sử dụng một tính năng bổ sung gọi là bộ đệm vòng để lưu trữ tạm thời. Bộ đệm vòng là một thuộc tính cho phép mạng tái sử dụng cùng một bộ nhớ cho dữ liệu khác nhau. Bộ nhớ trong bộ đệm vòng được giới hạn ở cùng một vị trí bộ nhớ mỗi lần. Bộ đệm vòng trên EIP-2935 chỉ được sử dụng để phục vụ cửa sổ phục vụ LỊCH SỬ yêu cầu, khi EIP-4788 và bộ chứng cứ trạng thái đèn báo cho phép chứng cứ chống lại bất kỳ tổ tiên nào.

Quy tắc và Đặc tả Lựa chọn Fork

Sau khi fork, khi mạng bắt đầu với những xem xét EIP này, tham số HISTORY_STORAGE_ADDRESS sẽ được gọi là SYSTEM_ADDRESS với đầu vào block.parent.hash (mặc định 32 byte), giới hạn gas là 30.000.000 và giá trị là 0. Quá trình này sẽ kích hoạt hàm set() của hợp đồng lịch sử.

Quy trình cắt sau đề xuất khác với quy trình cắt thông thường. Hoạt động set() này là một hoạt động hệ thống chung, nhưng cuộc gọi tuân theo những quy ước sau:

• Phải thực hiện đến khi hoàn thành
• Không tính vào giới hạn gas của khối
• Không tuân theo cơ chế đốt EIP-1559
• Nếu không có mã nào tồn tại tại ĐỊA_CHỈ_LƯU_TRỮ_LỊCH_SỬ, cuộc gọi phải thất bại mà không có lỗi nghiêm trọng.

Quy trình này phải điền vào thời gian khối của CỬA SỔ LỊCH SỬ để đáp ứng chu kỳ kích hoạt bộ đệm vòng. Hợp đồng lịch sử sẽ chỉ chứa băm cha của khối nhánh, được sử dụng như một băm tham chiếu và điểm bắt đầu băm mới.

Một hợp đồng lịch sử mã khối sẽ có hai hoạt động: get() và set(). Hoạt động set() được kích hoạt nếu người gọi của hợp đồng trong một giao dịch bằng với địa chỉ HỆ THỐNG được giới thiệu với EIP-4788. Nếu người gọi và địa chỉ HỆ THỐNG không bằng hoặc không thỏa mãn điều kiện, hoạt động get() sẽ được kích hoạt.

Phép toán get() được sử dụng trong EVM để định vị các hash khối. Nó cho phép người gọi cung cấp số khối họ đang truy vấn, nếu đầu vào calldata không phải là 32 byte (điều này có nghĩa là nó là một valid block.parent.hash) và nếu yêu cầu nằm ngoài phạm vi ([block.number-HISTORY_SERVE_WINDOW, block.number-1]), nó sẽ hoàn nguyên giao dịch.

Hàm set() lấy block.parent.hash làm đầu vào như calldata khi người gọi gọi hợp đồng bằng một giao dịch. Nó cũng thiết lập giá trị lưu trữ như calldata[0:32] tại block.number-1 % HISTORY_SERVE_WINDOW.

ĐỊA_CHỈ_LƯU_TRỮ_LỊCH_SỬ sẽ được triển khai thông qua EIP-4788, được đề cập ở trên như cách truy cập các block hash tại EVM trực tiếp thông qua lớp đồng thuận. ĐỊA_CHỈ_LƯU_TRỮ_LỊCH_SỬ sẽ có giá trị nonce là 1 và được miễn trừ khỏi tiêu chuẩn dọn dẹp nonce không của EIP-161.

BLOCKHASH Transition Logic

Một lo ngại về EIP này là cách chuyển đổi logic giải quyết BLOCKHASH sau khi hard fork diễn ra. Hai phương pháp chính đang được xem xét:

• Chờ cho HISTORY_SERVE_WINDOW khối để toàn bộ lịch sử liên quan được lưu trữ,
• Lưu tất cả các mã hash khối cuối cùng của HISTORY_SERVE_WINDOW trên khối fork.

Những nhà phát triển chọn lựa lựa chọn đầu tiên. Điều này thực tế hơn vì nó không đòi hỏi bất kỳ thay đổi tạm thời nào.

Sự khác biệt giữa EIP-2935 và các EIP tương tự là gì?

Các EIP tương tự đã được đề xuất trước đó để cho phép và đạt được việc thực thi không trạng thái. EIP-2935 khác biệt so với những đề xuất trước đó vì nó nhắm đến những phức tạp được nêu dưới đây.

• Phương pháp cấu trúc Trie: EIP-2935 không sử dụng cấu trúc giống như trie với nhiều lớp mà thay vào đó chọn một danh sách duy nhất. Ngược lại, EIP-4444 đề xuất cắt tỉa dữ liệu lịch sử trong các máy khách thực thi cũ hơn một năm. Các EIP khác với những hoài bão tương tự có Verkle trie như yêu cầu.
• Viết EIP trong Mã EVM: EIP-2935 không yêu cầu thay đổi trong EVM.
• Lưu trữ Băm Không Giới Hạn Theo Chuỗi: Lưu trữ băm không giới hạn theo chuỗi không hiệu quả. EIP này vượt qua vấn đề này bằng cách gói gọn các băm.

Xem xét về an ninh

Vì EIP-2935 sử dụng hợp đồng thông minh, nó có nguy cơ bị tấn công độc hại chi nhánh. Tuy nhiên, kích thước của gốc trạng thái khiến bất kỳ cố gắng cập nhật nào trở nên chậm và một cuộc tấn công độc hại trở nên đáng kể đắt đỏ hơn.

Nó có thể mang lại điều gì?

• Làm cho Hệ thống Oracle không tin cậy nhanh hơn: Trong các hệ thống oracles dựa trên Uniswap v2, bất kỳ ai có quyền truy cập nút Ethereum đều có thể tạo ra một bằng chứng về lưu trữ của Uniswap và gửi nó để được xác nhận trên chuỗi. Giá trung bình được xác định giữa khối hiện tại và khối được cung cấp trong bằng chứng, với bằng chứng được xác nhận lên đến 256 khối, vì blockHash hỗ trợ lên đến 256 khối. Nhờ vào EIP-2935, quá trình này có thể được cải thiện bằng cách cho phép truy cập vào các block hash cũ hơn, điều này có nghĩa là các bằng chứng có thể được xác nhận trong một khoảng thời gian dài hơn.
• Cho phép hợp đồng xem xét các khẳng định về trạng thái trước đó, mà không cần tin cậy: Cải thiện EIP-2935 tạo ra khả năng xem dữ liệu blockchain từ bên trong EVM, mà không cần tin cậy. Một khách hàng có thể truy vấn lịch sử, có được băm nó, và xác minh nó với các nút khác. Giải pháp này có thể làm cho các khách hàng nhẹ hiệu quả và dễ triển khai.
• Kết nối giữa L1 <> L2: Để xác minh một tin nhắn từ L2, L1 cần biết về các state roots và block hashes của L2. Tuy nhiên, L1 trong trạng thái hiện tại không thể truy cập được các block hashes tùy ý do giới hạn gas và ràng buộc kiến trúc. EIP-2935 cho phép L1 xác minh dữ liệu lịch sử tùy ý với khả năng truy vấn chứng minh sự bao gồm cho các sự kiện cũ. Sức mạnh truy cập và xác minh sẽ được cải thiện, và hiệu suất kết nối sẽ tốt hơn.

Kết luận

EIP-2935 đại diện cho một bước quan trọng đến mục tiêu dài hạn của Ethereum không có trạng thái. Lưu trữ 8192 mã băm khối cuối cùng trong một hợp đồng riêng trong các địa chỉ trạng thái giải quyết một hạn chế cơ bản trong thiết kế hiện tại. Giả định của Ethereum rằng các máy khách mặc định có quyền truy cập vào mã băm khối gần đây. Trong ngữ cảnh của thực thi không có trạng thái, khi các máy khách không còn duy trì toàn bộ trạng thái, giả định này trở nên lỗi thời. EIP-2935 giải quyết vấn đề này bằng cách giới thiệu một cơ chế nhẹ, hiệu quả và không xâm phạm cho phép các máy khách không có trạng thái truy cập vào dữ liệu lịch sử cần thiết mà không cần sửa đổi EVM hoặc phụ thuộc vào cấu trúc dữ liệu phức tạp như Verkle trie.

Ngoài việc thực hiện không có trạng thái, đề xuất này mở khóa những lợi ích rộng lớn hơn trong hệ sinh thái Ethereum. Nó nâng cao khả năng của các oracles không cần tin cậy, mở rộng tính khả dụng của các light clients, và tăng cường tính tương tác giữa các giải pháp Layer 1 và Layer 2 bằng cách cho phép xác minh đáng tin cậy của dữ liệu trạng thái cũ. Việc triển khai của nó phụ thuộc vào một thiết kế sạch sẽ và tiết kiệm gas, sử dụng lưu trữ vòng tròn và các hợp đồng cấp hệ thống mà tránh được việc cần phải hardcode vào EVM, đồng thời cung cấp cả tính đơn giản và tính mở rộng.

Khi Ethereum tiếp tục phát triển hướng tới sự phi tập trung, khả năng mở rộng và sự tiện lợi hơn, EIP-2935 đóng vai trò là sự cải tiến cơ bản. Nó cầu nối khoảng cách giữa kiến trúc stateful hiện tại và tương lai stateless được ước lượng và lập nền tảng cho cơ sở hạ tầng mạnh mẽ, hiệu quả và không cần phép tại hệ sinh thái blockchain.

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được sao chép từ [ 2077research]. Tất cả bản quyền thuộc về tác giả gốc [Yiğit Yektin]. Nếu có ý kiến ​​phản đối về việc tái in này, vui lòng liên hệ Học cửađội và họ sẽ xử lý ngay lập tức.
2. Miễn trừ trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc về tác giả và không đại diện cho bất kỳ lời khuyên đầu tư nào.
3. Nhóm Gate Learn thực hiện dịch các bài viết sang các ngôn ngữ khác. Việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch là không được phép trừ khi được đề cập.