Long câu chuyện ngắn: Việc nâng cấp Cancun đang đến gần và bản nâng cấp này chủ yếu bao gồm các thay đổi lớp điều hành được đề xuất bởi sáu EIP, EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780 và EIP-7516. EIP-4844 là nhân vật chính của bản nâng cấp này, nhằm cải thiện khả năng mở rộng của Ethereum, Thả Chi phí giao dịch L2 và tăng tốc độ giao dịch. Việc nâng cấp Cancun được hoàn thành vào ngày 17 tháng 1, 30 tháng 1, 7 tháng 2 tại Ethereum Goerli, Sepolia và Holesky Testnet, và dự kiến sẽ được kích hoạt vào ngày 13 tháng 3 năm Ethereum Mạng chính. Trước khi nâng cấp, Salus đã biên soạn các cân nhắc bảo mật quan trọng cho bản nâng cấp này để các nhà phát triển tự kiểm tra.
Đánh giá đề xuất KCN sinh thái
Các cân nhắc bảo mật được tiết lộ chính thức
Hợp đồng thông minh rủi ro liên quan
Đọc thêm
Đánh giá đề xuất KCN sinh thái
EIP-1153
EIP-1153 giới thiệu Mã thao tác lưu trữ tạm thời, Mã thao tác được sử dụng cho trạng thái hoạt động và hoạt động gần giống với lưu trữ, nhưng bị loại bỏ sau mỗi giao dịch hoàn thành. Điều này có nghĩa là lưu trữ tạm thời không khử tuần tự hóa các giá trị từ bộ nhớ và không tuần tự hóa các giá trị thành bộ nhớ, vì vậy lưu trữ tạm thời ít tốn kém hơn vì nó không yêu cầu quyền truy cập đĩa. Với hai Mã hoạt động mới, TLOAD và TSTORE (trong đó “T” là viết tắt của “tạm thời”), Hợp đồng thông minh có thể truy cập bộ nhớ tạm thời. Đề xuất này nhằm mục đích cung cấp một giải pháp chuyên dụng và hiệu quả để giao tiếp giữa Long khung thực thi lồng nhau trong quá trình thực hiện giao dịch của Ethereum.
EIP-4788
EIP-4788 nhằm mục đích phơi bày rễ cây băm của Khối chuỗi Beacon với EVM để cho phép truy cập vào các rễ này bên trong Hợp đồng thông minh. Làm như vậy cung cấp quyền truy cập không tin cậy vào trạng thái lớp Nhận thức chung, hỗ trợ các trường hợp sử dụng Long như nhóm đặt cọc, cấu trúc lấy lại, cầu Hợp đồng thông minh, giảm thiểu MEV và hơn thế nữa. Đề xuất lưu trữ các gốc này thông qua một Hợp đồng thông minh và sử dụng bộ đệm vòng để hạn chế tiêu thụ lưu trữ, đảm bảo rằng mỗi Khối thực thi chỉ cần một Short không đổi để thể hiện thông tin này.
EIP-4844
EIP-4844 giới thiệu một định dạng giao dịch mới được gọi là “Giao dịch Phân mảnh Blob” được thiết kế để mở rộng tính khả dụng của dữ liệu Ethereum một cách đơn giản, tương thích với chuyển tiếp. Đề xuất này thực hiện điều này bằng cách giới thiệu “các giao dịch mang blob” chứa một lượng lớn dữ liệu không thể truy cập được bằng cách thực thi EVM, nhưng có thể truy cập các lời hứa của nó. Định dạng này hoàn toàn tương thích với định dạng được sử dụng bởi Phân mảnh đầy đủ trong tương lai, cung cấp một cứu trợ tạm thời nhưng đáng kể cho việc mở rộng quy mô.
EIP-5656
EIP-5656 giới thiệu một lệnh EVM mới, MCOPY, để sao chép hiệu quả các vùng bộ nhớ. Đề xuất này nhằm mục đích Thả chi phí thực hiện các hoạt động sao chép bộ nhớ trên EVM bằng cách trực tiếp cho phép sao chép dữ liệu giữa các bộ nhớ thông qua lệnh MCOPY. MCOPY CHO PHÉP Địa chỉ Địa chỉ NGUỒN VÀ ĐÍCH CHỒNG CHÉO LÊN NHAU, ĐƯỢC THIẾT KẾ VỚI KHẢ NĂNG TƯƠNG THÍCH NGƯỢC VÀ ĐƯỢC THIẾT KẾ ĐỂ CẢI THIỆN HIỆU QUẢ THỰC THI TRONG CÁC KỊCH BẢN Long, BAO GỒM XÂY DỰNG CẤU TRÚC DỮ LIỆU, TRUY CẬP HIỆU QUẢ VÀO CÁC ĐỐI TƯỢNG TRONG BỘ NHỚ VÀ SAO CHÉP.
EIP-6780
EIP-6780 sửa đổi chức năng của Mã thao tác SELFDESTRUCT. Trong đề xuất này, SELFDESTRUCT sẽ chỉ xóa tài khoản và chuyển tất cả Ether trong cùng một giao dịch khi hợp đồng được tạo, ngoại trừ khi SELFDESTRUCT được thực hiện, hợp đồng sẽ không bị xóa mà chỉ đơn giản là chuyển tất cả Ether đến đích được chỉ định. Thay đổi này nhằm phù hợp với việc sử dụng cây Verkle trong tương lai và nhằm đơn giản hóa việc triển khai EVM và giảm sự phức tạp của các thay đổi trạng thái, trong khi vẫn giữ lại một số kịch bản phổ biến được sử dụng bởi SELFDESTRUCT.
EIP-7516
EIP-7516 giới thiệu một lệnh EVM mới, BLOBBASEFEE, trả về giá trị phí cơ sở blob trong thực thi khối hiện tại. Chỉ thị này tương tự như Mã thao tác BASEFEE trong EIP-3198, ngoại trừ việc nó trả về phí cơ sở blob theo định nghĩa của EIP-4844. Tính năng này cho phép hợp đồng xem xét theo chương trình giá gas của dữ liệu blob, ví dụ, bằng cách cho phép các hợp đồng tổng hợp tính toán chi phí sử dụng dữ liệu blob một cách đáng tin cậy hoặc triển khai hợp đồng tương lai khí blob dựa trên điều này để làm dịu chi phí dữ liệu blob.
Cân nhắc bảo mật được tiết lộ chính thức
EIP-1153
Hợp đồng thông minh nhà phát triển nên hiểu vòng đời của các biến lưu trữ tạm thời trước khi sử dụng chúng. Vì lưu trữ tạm thời được tự động xóa khi kết thúc giao dịch, các nhà phát triển Hợp đồng thông minh có thể cố gắng tránh xóa các vị trí trong các cuộc gọi để tiết kiệm gas. Tuy nhiên, điều này có thể ngăn chặn sự tương tác thêm với hợp đồng trong cùng một giao dịch (ví dụ: trong trường hợp khóa lại) hoặc gây ra các lỗi khác, vì vậy Hợp đồng thông minh nhà phát triển nên cẩn thận chỉ bảo toàn các giá trị khác 0 khi vị trí tạm thời được dành riêng. Dự định sẽ được sử dụng bởi các cuộc gọi trong tương lai trong cùng một giao dịch. SSTORE Mặt khác, các Mã hoạt động này hoạt động giống hệt như và SLOAD, vì vậy tất cả các cân nhắc bảo mật phổ biến đều được áp dụng, đặc biệt là khi nói đến rủi ro tái xâm nhập.
Hợp đồng thông minh nhà phát triển cũng có thể cố gắng sử dụng lưu trữ tạm thời như một giải pháp thay thế cho ánh xạ bộ nhớ. Họ nên lưu ý rằng lưu trữ tạm thời không bị loại bỏ như bộ nhớ khi cuộc gọi trở lại hoặc tiếp tục và bộ nhớ nên được ưu tiên trong các trường hợp sử dụng này để tránh hành vi không mong muốn khi tham gia lại trong cùng một giao dịch. Lưu trữ tạm thời trên bộ nhớ nhất thiết phải tốn kém, điều này lẽ ra phải ngăn chặn mô hình sử dụng này. Việc sử dụng ánh xạ trong bộ nhớ Long lớn có thể đạt được tốt hơn với danh sách mục nhập được sắp xếp bằng khóa và ánh xạ trong bộ nhớ hiếm khi được yêu cầu trong Hợp đồng thông minh (tức là tác giả biết rằng không có trường hợp sử dụng nào được biết đến trong sản xuất).
EIP-4844
EIP này làm tăng yêu cầu băng thông khoảng 0.75 MB ở mức tối đa Long trên mỗi khối đèn hiệu. Con số này lớn hơn 40% so với kích thước Khối tối đa lý thuyết ngày nay (30 M Gas / 16 Gas trên mỗi byte calldata = 1.875 M byte), vì vậy nó không làm tăng đáng kể băng thông trong trường hợp xấu nhất. Sau khi sáp nhập, thời gian Khối là tĩnh chứ không phải là phân phối Poisson không thể đoán trước, cung cấp một khoảng thời gian đảm bảo cho việc nhân giống Khối lớn.
Ngay cả với dữ liệu cuộc gọi hạn chế, tải duy trì của EIP này thấp hơn Long so với các lựa chọn thay thế có thể Thả chi phí dữ liệu cuộc gọi vì bạn không cần lưu trữ blob miễn là tải thực thi. Điều này làm cho nó có thể thực hiện một chính sách mà các đốm màu này phải được giữ lại trong ít nhất một khoảng thời gian nhất định. Giá trị cụ thể được chọn là kỷ nguyên MIN \ _EPOCHS \ _FOR \ _BLOB \ _SIDECARS \ _REQUESTS, xấp xỉ 18 ngày, với độ trễ Long so với vòng quay một năm được đề xuất (nhưng chưa được triển khai) của lịch sử tải trọng thực thi.
EIP-5656
Khách hàng nên lưu ý rằng việc triển khai của họ không sử dụng bộ đệm trung gian (ví dụ: hàm C stdlibmemmove không sử dụng bộ đệm trung gian), vì đây là vectơ từ chối dịch vụ (DoS) tiềm năng. Long các hàm thư viện tích hợp / tiêu chuẩn của ngôn ngữ để di chuyển byte có các đặc tính hiệu suất chính xác ở đây.
Ngoài ra, phân tích các cuộc tấn công từ chối dịch vụ (DoS) và cạn kiệt bộ nhớ cũng giống như các Mã thao tác khác để chạm vào bộ nhớ, bởi vì mở rộng bộ nhớ tuân theo các quy tắc định giá tương tự.
EIP-6780
CÁC ỨNG DỤNG TỰ HỦY SAU ĐÂY SẼ BỊ XÂM PHẠM VÀ CÁC ỨNG DỤNG SỬ DỤNG NÓ THEO CÁCH NÀY KHÔNG CÒN AN TOÀN NỮA:
WhereCREATE 2 được sử dụng để triển khai lại hợp đồng ở cùng một vị trí để hợp đồng có thể nâng cấp. Tính năng này không còn được hỗ trợ và ERC-2535 hoặc một loại hợp đồng proxy khác nên được sử dụng thay thế.
Nếu hợp đồng dựa vào việc đốt Ether bằng cách lấy hợp đồng SELFDESTRUCT làm người thụ hưởng, hợp đồng không được tạo ra trong cùng một giao dịch.
Rủi ro liên quan đến Hợp đồng thông minh
EIP 1153
Xem xét hai kịch bản bằng cách sử dụng TLOAD và TSTORE Mã thao tác:
- Hợp đồng được gọi sử dụng Mã thao tác
- Mã thao tác được sử dụng để khởi tạo hợp đồng cuộc gọi
Rủi ro 1:
So với SSTORE và SLOAD truyền thống, lưu trữ tạm thời mới chủ yếu thay đổi thời gian lưu trữ dữ liệu, dữ liệu được lưu trữ bởi tstore được đọc qua tload và dữ liệu sẽ được giải phóng sau khi thực hiện giao dịch, thay vì được ghi vào hợp đồng như sstore được ghi lại vĩnh viễn. Các nhà phát triển nên nhận ra các tính năng của Mã thao tác khi sử dụng Mã thao tác, để tránh tổn thất do sử dụng dữ liệu không chính xác không thể được ghi vào hợp đồng một cách chính xác. Ngoài ra, dữ liệu của tstore là một biến riêng và chỉ có thể được truy cập bởi chính hợp đồng. Nếu bạn muốn sử dụng dữ liệu bên ngoài, bạn chỉ có thể truyền nó dưới dạng tham số hoặc dàn dựng nó trong một biến stroage công khai.
Rủi ro 2:
Một rủi ro tiềm ẩn khác là nếu các nhà phát triển Hợp đồng thông minh không quản lý đúng vòng đời của các biến lưu trữ tạm thời, nó có thể dẫn đến việc dữ liệu bị xóa hoặc giữ lại không chính xác vào những thời điểm không chính xác. Nếu hợp đồng dự kiến sử dụng dữ liệu được lưu trữ trong bộ lưu trữ tạm thời trong các cuộc gọi tiếp theo đến một giao dịch, nhưng không quản lý đúng vòng đời của dữ liệu đó, dữ liệu có thể bị chia sẻ nhầm hoặc bị mất giữa các cuộc gọi khác nhau, dẫn đến lỗi logic hoặc vi phạm bảo mật. Xem xét rằng dữ liệu số dư hoặc phụ cấp của một dự án Token tương tự không được lưu trữ chính xác, nó sẽ dẫn đến sai sót trong logic hợp đồng và gây ra tổn thất. Hoặc việc sử dụng Mã thao tác này khi đặt Địa chỉ chủ sở hữu sẽ khiến Địa chỉ đặc quyền không được ghi lại chính xác, do đó làm mất việc sửa đổi các thông số quan trọng của hợp đồng.
Hãy xem xét một Hợp đồng thông minh sử dụng lưu trữ tạm thời để tạm thời ghi lại giá giao dịch trên nền tảng giao dịch Tài sản tiền điện tử. Hợp đồng cập nhật giá khi mỗi giao dịch được hoàn thành và cho phép người dùng truy vấn giá mới nhất trong một khoảng thời gian ngắn. Tuy nhiên, nếu thiết kế hợp đồng không tính đến thực tế là lưu trữ tạm thời được tự động xóa khi kết thúc giao dịch, thì người dùng có thể nhận được giá sai hoặc lỗi thời trong khoảng thời gian từ khi kết thúc một giao dịch đến khi bắt đầu giao dịch tiếp theo. Điều này có thể không chỉ khiến người dùng đưa ra quyết định dựa trên thông tin sai lệch mà còn có thể bị khai thác ác ý, ảnh hưởng đến uy tín của nền tảng và bảo mật tài sản của người dùng.
EIP-6780
Đề xuất thay đổi hành vi trước đây của Mã thao tác tự hủy, không phá hủy hợp đồng, chỉ chuyển mã thông báo và chỉ hợp đồng được tạo trong cùng một giao dịch với tự hủy sẽ bị hủy. Tác động của KCN sinh thái này tương đối lớn.
Triển khai lại hợp đồng cùng Địa chỉ với tạo 2 để nâng cấp hợp đồng. Tính năng này không còn được hỗ trợ và ERC-2535 hoặc một loại hợp đồng proxy khác nên được sử dụng thay thế. (Điều này có thể ảnh hưởng đến tính bảo mật của các hợp đồng on-chain sử dụng create 2 để thực hiện các hợp đồng có thể mở rộng)
Hoạt động SELFDESTRUCT trong Hợp đồng thông minh cho phép hủy hợp đồng và số dư hợp đồng được gửi đến Địa chỉ đích được chỉ định. Trong trường hợp này, hợp đồng sử dụng SELFDESTRUCT để đốt cháy Ether và gửi Ether bị đốt cháy vào hợp đồng. Tuy nhiên, hợp đồng chỉ có thể là hợp đồng được tạo lập trong cùng một giao dịch (hợp đồng được tạo ra bởi hợp đồng này hoặc hợp đồng khác trong cùng một giao dịch). Nếu không, chỉ có Ether sẽ được chuyển nhượng mà không phá hủy hợp đồng (ví dụ: tự hủy và người thụ hưởng là hợp đồng tự hủy, sẽ không thay đổi bất cứ điều gì). Điều này sẽ ảnh hưởng đến bất kỳ hợp đồng nào dựa vào việc tự hủy để rút tiền hoặc các hoạt động khác.
Một mã thông báo gas tương tự như 1inch CHI Token hoạt động: giữ phần bù, luôn thực hiện CREATE 2 hoặc SELFDESTRUCT ở phần bù đó. Sau bản cập nhật này, nếu hợp đồng với phần bù hiện tại chưa tự hủy chính xác, CREATE 2 tiếp theo sẽ không thể triển khai thành công hợp đồng.
Việc thực hiện đề xuất này sẽ không dẫn đến một cuộc tấn công trực tiếp vào hợp đồng, nhưng nó sẽ làm hỏng logic thông thường của hợp đồng được triển khai ban đầu dựa trên hoạt động tự hủy (hợp đồng chỉ dựa vào tự hủy để chuyển tiền sẽ không bị ảnh hưởng và nếu hoạt động tiếp theo phải yêu cầu xóa hợp đồng tự hủy thì sẽ bị ảnh hưởng), dẫn đến hợp đồng không hoạt động như dự định và chỉ đối với hợp đồng và người dùng, nó có thể dẫn đến đình công của hợp đồng, mất tiền và các tác hại khác (chẳng hạn như việc sử dụng ban đầu tạo 2). Triển khai hợp đồng mới tại Địa chỉ ban đầu và hợp đồng tự hủy hợp đồng nâng cấp ban đầu không còn có thể triển khai thành công). Về lâu dài, khả năng sửa đổi một Mã thao tác có thể dẫn đến các vấn đề tập trung.
Ví dụ: có một vault hợp đồng vault hiện có để cập nhật:
- Tạo 2 Hợp đồng lưu trữ tạm thời được sử dụng để tạm thời dự trữ tiền cho kho tiền
- Hợp đồng kho tiền tự hủy, chuyển tiền sang hợp đồng tạm thời (chỉ chuyển tiền, không đốt hợp đồng)
- Hợp đồng vault mới tại Địa chỉ ban đầu tạo 2 (không thành công vì hợp đồng vault ban đầu không bị hủy)
- Hợp đồng tạm thời tự hủy để trả lại tiền vào kho tiền (mất tiền, hợp đồng kho tiền không được tạo)
Đọc thêm
Việc nâng cấp Cancun sẽ nâng cao hơn nữa lợi thế cạnh tranh của Ethereum. Tuy nhiên, việc nâng cấp này đặt ra rủi ro đối với những thay đổi đối với lớp Hợp đồng thông minh lõi, điều này sẽ ảnh hưởng đến hoạt động an toàn của các DApp hiện có. Trong quá trình phát triển Hợp đồng thông minh, những thay đổi này và những rủi ro có thể phát sinh cũng cần được quan tâm chặt chẽ. Bạn có thể liên hệ với Salus để kiểm tra rủi ro hoặc hỗ trợ kiểm toán, hoặc bạn có thể đọc thêm để hiểu các thay đổi.
Đặc điểm kỹ thuật nâng cấp mạng Cancun
EIP-1153
EIP-4788
EIP-4844
EIP-5656
EIP-6780
EIP-7516
Hợp đồng Metapod
Hợp đồng GasToken 2
