BTC

$96,000

5.73%

ETH

$3,521.91

3.97%

HTX

$0.{5}2273

5.23%

SOL

$198.17

3.05%

BNB

$710

3.05%

简体中文

繁體中文

English

Tiếng Việt

한국어

日本語

ภาษาไทย

Türkçe

Partnered With:

Hard fork Berlin sẽ có tác động như thế nào đến Gas?

Đọc bài viết này mất 24 phút

Hard fork Berlin thay đổi chi phí gas cho một số opcode

Tiêu đề gốc: "Hard fork Berlin sẽ có tác động như thế nào đến Gas?" 》

Nguồn gốc: Cộng đồng Trung Quốc ECN Ethereum

Hard fork Berlin đã được ra mắt trên mạng chính vào ngày 14 tháng 4. Bốn EIP đã được giới thiệu. Hai trong số đó (EIP-2929 và EIP-2930) có tác động đến chi phí gas của giao dịch. Bài viết này sẽ giải thích cách tính một số chi phí gas trước Berlin, chúng thay đổi như thế nào khi đưa vào EIP-2929 và cách sử dụng danh sách truy cập do EIP-2930 giới thiệu.

Tóm tắt những điểm chính

Bài viết này khá dài, đây là phần tóm tắt:

Berlin Hard Forking thay đổi chi phí gas của một số opcode. Nếu giá trị phí gas được mã hóa cứng trong dapp hoặc hợp đồng thông minh, chúng có thể bị hủy bỏ. Nếu điều này xảy ra và hợp đồng thông minh không thể cập nhật được, người tiêu dùng sẽ cần sử dụng danh sách truy cập EIP-2930 để sử dụng phần opcode đó.

Danh sách truy cập có thể được sử dụng để giảm một lượng nhỏ chi phí gas, nhưng trên thực tế, chúng trong một số trường hợp Nó sẽ làm tăng tổng lượng khí tiêu thụ.

geth đã thêm một phương thức RPC mới có tên là eth_createAccessList để đơn giản hóa việc tạo danh sách truy cập.

Chi phí gas trước hard fork Berlin

Mỗi opcode được EVM thực thi đều có chi phí gas liên quan. Hầu hết chúng đều có chi phí cố định: PUSH1 luôn có giá 3 đơn vị gas, MUL có giá 5, v.v. Những thứ khác khác nhau: Ví dụ: chi phí opcode của SHA3 phụ thuộc vào kích thước đầu vào của nó.

Chúng tôi chủ yếu thảo luận về các opcode SLOAD và SSTORE, bởi vì chúng bị ảnh hưởng nhiều nhất bởi cuộc khủng hoảng Berlin ngã ba của. Chúng ta sẽ thảo luận về các mã hoạt động theo địa chỉ cụ thể sau, chẳng hạn như tất cả EXT* và CALL*, vì chi phí gas của chúng cũng đã thay đổi.

Chi phí gas của SLOAD trước Berlin

Trước EIP-2929, Gas chi phí của SLOAD rất đơn giản: nó luôn có giá 800 gas. Vì vậy, không có nhiều điều để nói (chưa).

Giá gas của SSTORE trước Berlin

SSTORE có lẽ là opcode phức tạp nhất về mặt tiêu thụ gas, bởi vì chi phí của nó phụ thuộc vào những thứ như lưu trữ giá trị hiện tại của slot, giá trị mới của nó và liệu nó đã được sửa đổi trước đó hay chưa . Chúng tôi

chỉ phân tích một số tình huống để hiểu cơ bản, nếu bạn muốn biết thêm, vui lòng đọc liên kết EIP ở cuối bài viết.

Nếu giá trị của vị trí được lưu trữ thay đổi từ 0 thành 1 (hoặc bất kỳ giá trị nào khác hơn giá trị 0), lượng gas tiêu thụ là 20.000.

Nếu giá trị khe lưu trữ thay đổi từ 1 thành 2 (hoặc bất kỳ giá trị nào khác khác 0), thì mức tiêu thụ gas là 5000.

Nếu giá trị của khe lưu trữ thay đổi từ 1 (hoặc bất kỳ giá trị nào khác 0) thành 0 thì mức tiêu thụ gas cũng là 5000, nhưng khi kết thúc giao dịch bạn sẽ được hoàn lại 1 gas. Bài viết này sẽ không thảo luận về việc hoàn trả phí gas vì chúng không bị ảnh hưởng trong đợt hard fork Berlin.

Nếu giá trị của khe lưu trữ được sửa đổi trong cùng một giao dịch trước đó, mức tiêu thụ gas của tất cả các SSTORE tiếp theo sẽ là 800.

Chi tiết phần này không có gì thú vị, quan trọng là SSTORE đắt tiền, và mức tiêu thụ của nó phụ thuộc vào một số yếu tố.

Tiêu thụ khí sau EIP-2929

EIP-2929 ảnh hưởng đến mức tiêu thụ gas của tất cả các opcode trên. Nhưng trước khi đi sâu vào những thay đổi này, chúng ta cần nói về một khái niệm quan trọng được EIP này đưa ra: địa chỉ được truy cập và khóa lưu trữ được truy cập.

Nếu một địa chỉ hoặc khóa lưu trữ đã được "sử dụng" trong giao dịch trước đó, thì chúng sẽ được coi là "đã ghé thăm". Ví dụ: khi bạn GỌI một hợp đồng khác, địa chỉ của hợp đồng đó sẽ được đánh dấu là "đã truy cập". Tương tự như vậy, khi bạn TẢI hoặc SSTORE một số vị trí, phần còn lại của giao dịch

Các phần khác cũng sẽ được coi là đã ghé thăm. Việc opcode nào thực hiện nó không quan trọng: nếu SLOAD đọc một vị trí thì các SLOAD và SSTORE tiếp theo đều được coi là đã truy cập.

Điều đáng chú ý ở đây là khóa lưu trữ được "tích hợp sẵn" trong một số địa chỉ. EIP này giải thích: "Khi thực hiện một giao dịch, hãy duy trì một tập hợp các địa chỉ access_addresses: Set[Address] và accessed_storage_keys: Set[Tuple[Address, Bytes32]] "

Nói cách khác, khi chúng ta nói rằng một khe lưu trữ đã được truy cập, chúng ta thực sự đang nói rằng một cặp (địa chỉ, storageKey) đã được truy cập.

Hãy nói về mức tiêu thụ khí đốt mới.

TẢI sau Berlin

Trước hard fork Berlin, SLOAD đã tiêu thụ một lượng gas cố định là 800. Bây giờ, nó phụ thuộc vào việc khe lưu trữ đã được truy cập hay chưa. Nếu chưa truy cập được thì mức tiêu thụ gas là 2100; nếu chưa được truy cập thì mức tiêu thụ gas là 100. Do đó, nếu khe cắm nằm trong danh sách khóa lưu trữ được truy cập thì mức tiêu thụ gas của SLOAD sẽ nhỏ hơn 2000.

SSTORE sau Berlin

;

Chúng ta hãy xem lại ví dụ SSTORE trước đó trong bối cảnh EIP-2929:

➤ Nếu giá trị của khe lưu trữ thay đổi từ 0 thành 1 (hoặc bất kỳ giá trị nào khác 0) thì lượng gas tiêu thụ là:

Nếu khóa lưu trữ chưa được truy cập, 22100

Nếu khóa lưu trữ chưa được truy cập, 20000

➤ Nếu giá trị của khe lưu trữ thay đổi từ 1 thành 2 (hoặc bất kỳ giá trị nào khác khác 0), lượng gas tiêu thụ là:

Nếu chưa truy cập được khóa lưu trữ, 5000

Nếu đã ghé thăm, 2900

➤ Nếu giá trị của khe lưu trữ thay đổi từ 1 (hoặc bất kỳ giá trị nào khác 0) thành 0, mức tiêu thụ gas giống như trường hợp trước, cộng với lợi nhuận.

➤ Nếu giá trị của vị trí được lưu trữ được sửa đổi trong cùng một giao dịch trước đó, tất cả các giao dịch tiếp theo sẽ mức tiêu thụ gas của SSTORE là 100.

Như bạn có thể thấy, nếu vị trí được SSTORE sửa đổi đã được truy cập trước đó, thì An SSTORE tiêu thụ ít hơn 2100 gas.

Tóm tắt

Bảng sau so sánh các giá trị trên:

Lưu ý rằng ở dòng cuối cùng không cần nói về việc slot đã được truy cập hay chưa, bởi vì nếu nó đã được truy cập trước khi được viết, sau đó nó đã được truy cập.

EIP-2930: Giao dịch danh sách truy cập tùy chọn

EIP khác mà chúng tôi đã đề cập ở phần đầu là EIP-2930. EIP này thêm một loại giao dịch mới có thêm danh sách truy cập vào giao dịch. Điều này có nghĩa là bạn có thể khai báo trước những địa chỉ và vị trí nào sẽ được xem xét truy cập trước khi bắt đầu thực hiện giao dịch. Ví dụ: SLOAD cho một vị trí không được truy cập sẽ tốn 2100 gas, nhưng nếu vị trí đó được thêm vào danh sách truy cập giao dịch thì cùng một opcode chỉ tốn 100 gas.

Nhưng nếu địa chỉ hoặc khóa lưu trữ đã được truy cập, nó sẽ tiêu tốn ít gas hơn. nghĩa là chúng ta có thể thêm mọi thứ vào danh sách truy cập giao dịch để giảm mức tiêu thụ gas? Tuyệt vời! Không cần phải trả tiền xăng! Tuy nhiên, điều này không nhất thiết phải như vậy vì bạn vẫn phải trả phí gas mỗi khi thêm địa chỉ và lưu trữ chìa khóa.

Hãy xem một ví dụ. Nếu chúng tôi gửi giao dịch đến hợp đồng A, danh sách truy cập có thể như sau:

Nếu chúng tôi gửi một giao dịch được đính kèm Đối với các giao dịch có danh sách truy cập này, opcode đầu tiên sử dụng slot0x0 là SLOAD, tiêu thụ 100 gas thay vì 2100 gas. Điều này làm giảm khí đốt vào năm 2000. Tuy nhiên, việc thêm khóa lưu trữ vào danh sách truy cập của giao dịch sẽ tốn 1900 gas mỗi lần. Vậy là chúng ta chỉ tiết kiệm được 100 gas. (Nếu opcode đầu tiên truy cập vào khe là SSTORE thay vì SLOAD, chúng ta có thể tiết kiệm được 2100 gas, điều đó có nghĩa là nếu chúng ta xem xét chi phí lưu trữ khóa, chúng ta sẽ tiết kiệm được tổng cộng 200 gas.)

Điều này có nghĩa là chúng ta có thể tiết kiệm xăng miễn là chúng ta truy cập vào danh sách bằng cách sử dụng các giao dịch? Không, bởi vì chúng tôi cũng cần trả phí gas để thêm địa chỉ vào danh sách truy cập (tức là "<địa chỉ của A>" trong ví dụ của chúng tôi).

Địa chỉ đã truy cập

Cho đến nay, chúng ta chỉ thảo luận về các opcode SLOAD và SSTORE, nhưng đây không phải là những opcode duy nhất đã thay đổi sau khi nâng cấp Berlin. Ví dụ: chi phí cố định trước opcode CALL là 700. Nhưng sau EIP-2929, nếu địa chỉ không có trong danh sách truy cập thì mức tiêu thụ của nó sẽ là 2600 và nếu có thì là 100. Ngoài ra, giống như khóa lưu trữ được truy cập, bất kể opcode nào đã được truy cập trước đó (ví dụ: nếu EXTCODESIZE được gọi lần đầu tiên thì opcode này sẽ tiêu tốn 2600 gas và bất kỳ EXTCODESIZE nào tiếp theo sử dụng cùng một địa chỉ sẽ tiêu tốn 2600 gas. , GỌI hoặc TÌNH TRẠNG GỌI chỉ tiêu tốn 100 gas).

Điều này ảnh hưởng như thế nào đến các giao dịch với danh sách truy cập? Ví dụ: nếu chúng ta gửi một giao dịch đến hợp đồng A và hợp đồng đó gọi một hợp đồng B khác thì chúng ta có thể thêm danh sách như vậy:

Chúng ta sẽ cần trả 2400 gas để thêm danh sách truy cập này vào giao dịch, nhưng khi đó opcode đầu tiên sử dụng địa chỉ B chỉ tốn 100 gas thay vì 2600. Vậy là chúng ta đã tiết kiệm được 100 xăng bằng cách làm này. Nếu B sử dụng bộ nhớ của nó theo cách nào đó và chúng tôi biết khóa nào được sử dụng thì chúng tôi cũng có thể thêm chúng vào danh sách truy cập, điều này có thể tiết kiệm 100 ~ 200 gas cho mỗi khóa (tùy thuộc vào mã opcode đầu tiên của bạn là SLOAD hay SSTORE ) .

Nhưng tại sao chúng ta lại nói về một hợp đồng khác? Còn hợp đồng mà chúng ta đang gọi thì sao? Tại sao không thực hiện các hoạt động này trên hợp đồng này?

Chúng tôi có thể làm điều này, nhưng nó không hiệu quả về mặt chi phí vì EIP-2929 quy định rõ ràng rằng địa chỉ của hợp đồng được gọi (tức là tx.to) sẽ được thêm vào danh sách access_addresses. Bởi vì

Chúng tôi không phải trả thêm 2400 xăng.

Chúng ta hãy phân tích ví dụ trước:

Trừ khi chúng ta muốn thêm một số khóa lưu trữ nữa, điều này thực sự là một sự lãng phí. Nếu chúng tôi mặc định SLOAD luôn sử dụng khóa lưu trữ trước tiên thì chúng tôi cần ít nhất 24 khóa lưu trữ để duy trì vốn.

Như bạn có thể tưởng tượng, việc phân tích không thú vị bằng việc tạo danh sách truy cập theo cách thủ công. May mắn thay, có một cách tốt hơn.

eth_createAccessList Phương thức RPC

Geth (kể từ phiên bản 1.10.2) đã thêm phương thức eth_createAccessListRPC mới mà bạn có thể sử dụng để tạo danh sách truy cập. Cách sử dụng của nó tương tự như eth_estimateGas , nhưng thay vì trả về ước tính gas, nó trả về kết quả như sau:

Nghĩa là, nó cung cấp cho bạn danh sách các địa chỉ và khóa lưu trữ được sử dụng trong giao dịch, cộng với lượng gas tiêu thụ khi thêm danh sách truy cập. (Giống như eth_estimateGas, đây là ước tính và danh sách này có thể thay đổi khi giao dịch được khai thác thực sự.) Tuy nhiên, điều này không có nghĩa là mức tiêu thụ gas sẽ thấp hơn so với việc gửi cùng một giao dịch mà không truy cập vào danh sách đã tiêu thụ!

Tôi nghĩ chúng ta sẽ tìm ra cách phù hợp để sử dụng nó theo thời gian, nhưng đây là suy đoán của tôi bằng mã giả:

Hủy ràng buộc hợp đồng

Điều đáng nói là mục đích chính của việc truy cập danh sách không phải là sử dụng gas. Như EIP giải thích:

"Giảm thiểu rủi ro phá vỡ hợp đồng do EIP-2929 đưa ra vì các giao dịch có thể chỉ định trước các tài khoản và lưu trữ các kế hoạch giao dịch để truy cập vào vị trí và thanh toán trước; cuối cùng trong quá trình thực thi thực tế, các opcode SLOAD và EXT* chỉ tiêu thụ 100 gas: mức tiêu thụ gas thấp này không chỉ ngăn ngừa sự gián đoạn do EIP này gây ra mà còn "nới lỏng" mọi sự gián đoạn do EIP-1884 bị hạn chế gây ra Hợp đồng. ”

Điều này có nghĩa là nếu một hợp đồng đưa ra các giả định về chi phí thực hiện một giao dịch thì chi phí gas có thể tăng lên. Đã dừng làm việc. Ví dụ: một hợp đồng gọi một hợp đồng khác như thế này someOtherContract.someFunction{gas: 34500}() sẽ gây ra sự cố vì nó cho rằng someFunction sẽ tiêu thụ chính xác 34500 gas. Nhưng nếu bạn thêm danh sách truy cập hợp lý thì hợp đồng sẽ hoạt động trở lại.

Tự kiểm tra

Nếu bạn muốn tự mình kiểm tra, hãy tạo một bản sao của cơ sở mã này, trong đó có nhiều phiên bản có thể được thực thi bằng Hardhat và geth. Xem hướng dẫn trong README.