Tóm tắt câu chuyện: Bản nâng cấp Cancun đang đến gần và bản nâng cấp này chủ yếu chứa các thay đổi cấ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 mục đích cải thiện khả năng mở rộng của Ethereum, giảm chi phí giao dịch và tăng tốc độ giao dịch cho L2. Bản nâng cấp Cancun đã được hoàn thành trên các mạng thử nghiệm Ethereum Goerli, Sepolia và Holesky lần lượt vào ngày 17 tháng 1, ngày 30 tháng 1 và ngày 7 tháng 2 và dự kiến sẽ được kích hoạt trên mạng chính Ethereum vào ngày 13 tháng 3. Trước khi nâng cấp, Salus đã biên soạn các biện pháp phòng ngừa an toàn quan trọng cho bản nâng cấp này để các nhà phát triển tự kiểm tra.
Chính thức tiết lộ những cân nhắc về an ninh
Rủi ro liên quan đến hợp đồng thông minh
Đánh giá đề xuất EIP
EIP-1153
EIP-1153 đã giới thiệu các mã lưu trữ tạm thời, được sử dụng để thao tác trạng thái và hoạt động gần giống như lưu trữ, nhưng lưu trữ tạm thời sẽ bị loại bỏ sau mỗi giao dịch. Điều này có nghĩa là bộ lưu trữ tạm thời không giải tuần tự hóa các giá trị từ hoặc tuần tự hóa các giá trị vào bộ lưu trữ, do đó, bộ lưu trữ tạm thời sẽ ít tốn kém hơn do không cần truy cập vào đĩa. Hợp đồng thông minh có thể truy cập vào bộ lưu trữ tạm thời thông qua hai mã opcode mới là TLOAD và TSTORE (trong đó “T” là viết tắt của “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ả để liên lạc giữa nhiều 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 đưa các gốc cây băm của các khối chuỗi đèn hiệu tới EVM để cho phép truy cập vào các gốc này trong các hợp đồng thông minh. Điều này cung cấp quyền truy cập không đáng tin cậy vào trạng thái lớp đồng thuận, hỗ trợ nhiều trường hợp sử dụng như nhóm đặt cược, cấu trúc đặt lại, cầu nối hợp đồng thông minh, giảm thiểu MEV, v.v. Đề xuất lưu trữ các gốc này thông qua hợp đồng thông minh và sử dụng bộ đệm vòng để hạn chế mức tiêu thụ bộ nhớ, đảm bảo rằng mỗi khối thực thi chỉ yêu cầu không gian 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 gọi là"Giao dịch Blob được phân chia", được thiết kế để mở rộng tính khả dụng của dữ liệu Ethereum theo cách đơn giản, tương thích về phía trước. Đề xuất này giới thiệu một lượng lớn dữ liệu"blob-carrying transactions", dữ liệu này không thể được truy cập bằng quá trình thực thi EVM, nhưng các cam kết của nó có thể được truy cập. Định dạng này hoàn toàn tương thích với định dạng được sử dụng bởi sharding hoàn toàn trong tương lai, mang lại sự hỗ trợ tạm thời nhưng đáng kể cho việc mở rộng luân phiên.
EIP-5656
EIP-5656 giới thiệu 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 giảm chi phí thực hiện các hoạt động sao chép bộ nhớ trên EVM bằng cách sao chép trực tiếp dữ liệu giữa các bộ nhớ thông qua lệnh MCOPY. MCOPY cho phép địa chỉ nguồn và đích chồng lên nhau, được thiết kế có tính tương thích ngược và nhằm mục đích cải thiện hiệu quả thực thi trong nhiều tình huống khác nhau bao gồm xây dựng cấu trúc dữ liệu, truy cập và sao chép hiệu quả các đối tượng bộ nhớ.
EIP-6780
EIP-6780 Đã sửa đổi chức năng của opcode SELFDESTRUCT. Trong đề xuất này, SELFDESTRUCT sẽ chỉ xóa tài khoản và chuyển toàn bộ ether trong cùng giao dịch với hợp đồng đã được tạo. Ngoài ra, khi thực hiện SELFDESTRUCT, hợp đồng sẽ không bị xóa mà toàn bộ ether sẽ được chuyển đến đích đã chỉ định. Thay đổi này nhằm thích ứng với việc sử dụng cây Verkle trong tương lai, nhằm đơn giản hóa việc triển khai EVM và giảm độ phức tạp của các thay đổi trạng thái, đồng thời giữ lại một số kịch bản chung của SELFDESTRUCT.
EIP-7516
EIP-7516 giới thiệu lệnh EVM mới BLOBBASEFEE trả về giá trị phí cơ sở blob trong quá trình thực thi khối hiện tại. Lệnh này tương tự như mã hoạt động BASEFEE từ EIP-3198, ngoại trừ việc nó trả về phí cơ sở blob như được xác định trong EIP-4844. Tính năng này cho phép các hợp đồng tính đến giá gas của dữ liệu blob theo chương trình, ví dụ: 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 giảm chi phí dữ liệu blob.
Chính thức tiết lộ những cân nhắc về an ninh
EIP-1153
Các nhà phát triển hợp đồng thông minh 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ì bộ nhớ tạm thời sẽ tự động bị xóa khi kết thúc giao dịch, nên 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 xăng. Tuy nhiên, điều này có thể ngăn chặn sự tương tác tiếp theo với hợp đồng trong cùng một giao dịch (ví dụ: trong trường hợp khóa đăng ký lại) hoặc gây ra các lỗi khác, vì vậy các nhà phát triển hợp đồng thông minh nên cẩn thận chỉ dành các khe lưu trữ không tạm thời khi chúng được đặt trước. Giá trị bằng không. Dự định sử dụng cho các cuộc gọi trong tương lai trong cùng một giao dịch. Mặt khác, các mã hoạt động này hoạt động chính xác như SSTORE và SLOAD , do đó, tất cả các cân nhắc bảo mật thông thường đều được áp dụng, đặc biệt là liên quan đến rủi ro đăng nhập lại.
Các nhà phát triển hợp đồng thông minh cũng có thể thử sử dụng bộ nhớ tạm thời thay thế cho việc ánh xạ bộ nhớ. Họ nên biết rằng bộ nhớ tạm thời không bị loại bỏ giống như bộ nhớ khi cuộc gọi quay lại hoặc tiếp tục và bộ nhớ nên được ưu tiên trong những trường hợp sử dụng này để tránh hành vi không mong muốn khi đăng nhập lại trong cùng một giao dịch. Chi phí lưu trữ tạm thời trên bộ nhớ nhất thiết phải cao, điều này đáng lẽ không khuyến khích kiểu sử dụng này. Hầu hết việc sử dụng ánh xạ trong bộ nhớ được triển khai tốt hơn với danh sách các mục nhập được sắp xếp theo thứ tự khóa và hiếm khi cần ánh xạ trong bộ nhớ trong hợp đồng thông minh (tức là các tác giả biết rằng không có trường hợp sử dụng nào đã biết trong sản xuất).
EIP-4844
EIP này tăng yêu cầu băng thông lên tới khoảng 0,75 MB cho mỗi khối báo hiệu. Con số này lớn hơn 40% so với kích thước tối đa theo lý thuyết của các khối ngày nay (30 M Gas / 16 Gas trên mỗi byte dữ liệu cuộc gọi = 1,875 M Byte), do đó, nó không làm tăng đáng kể băng thông trong trường hợp xấu nhất. Sau khi hợp nhất, thời gian của khối là phân phối Poisson tĩnh thay vì không thể đoán trước, cung cấp khoảng thời gian đảm bảo cho việc truyền bá các 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 nhiều so với các lựa chọn thay thế giúp giảm chi phí dữ liệu cuộc gọi vì các đốm màu không cần được lưu trữ miễn là tải được thực thi. Điều này giúp có thể thực hiện chính sách trong đó các đốm màu này phải được giữ lại ít nhất một thời gian. Giá trị cụ thể được chọn là kỷ nguyên MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS, tức là khoảng 18 ngày, độ trễ ngắn hơn nhiều so với vòng quay một năm được đề xuất (nhưng chưa được triển khai) để thực thi lịch sử tải trọng.
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. Hầu hết các hàm thư viện chuẩn/tích hợp ngôn ngữ để di chuyển byte đều có các đặc tính hiệu suất chính xác ở đây.
Mặt khác, việc phân tích các cuộc tấn công từ chối dịch vụ (DoS) và làm cạn kiệt bộ nhớ cũng giống như đối với các opcode khác chạm vào bộ nhớ vì các phần mở rộng bộ nhớ tuân theo các quy tắc định giá giống nhau.
EIP-6780
Ứng dụng sau đây SELFDESTRUCT sẽ bị hỏng và các ứng dụng sử dụng nó theo cách này không còn an toàn nữa:
Trong đóCREATE 2 được sử dụng để triển khai lại hợp đồng ở cùng một vị trí để làm cho hợp đồng có thể nâng cấp được. Tính năng này không còn được hỗ trợ nữa và thay vào đó, nên sử dụng ERC-2535 hoặc một loại hợp đồng proxy khác.
Nếu một hợp đồng dựa vào việc đốt ether bằng cách có hợp đồng SELFDESTRUCT làm người thụ hưởng thì hợp đồng đó sẽ không được tạo trong cùng một giao dịch.
Rủi ro liên quan đến hợp đồng thông minh
EIP 1153
Hãy xem xét hai kịch bản sử dụng opcode TLOAD và TSTORE:
Hợp đồng được gọi sử dụng opcode này
Sử dụng opcode này để bắt đầu cuộc gọi đến hợp đồng
Rủi ro 1:
So với SSTORE và SLOAD truyền thống, bộ 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ữ trong tstore được đọc qua tload. Dữ liệu sẽ được giải phóng sau khi thực hiện giao dịch chứ không phải cùng một lúc. để lưu trữ được ghi lại vĩnh viễn. Nhà phát triển nên nhận biết đặc điểm của opcode này khi sử dụng để tránh sử dụng sai có thể khiến dữ liệu ghi sai vào hợp đồng và gây thiệt hại. Ngoài ra, dữ liệu trong tstore là các biến riêng tư và chỉ có chính hợp đồng mới có thể truy cập được. Nếu muốn sử dụng dữ liệu bên ngoài, bạn chỉ có thể chuyển dữ liệu đó dưới dạng tham số hoặc lưu trữ tạm thời 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 cách thời gian tồn tại của các biến lưu trữ tạm thời, điều đó có thể dẫn đến việc dữ liệu bị xóa khi không cần thiết hoặc được giữ lại 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 lệnh gọi giao dịch tiếp theo nhưng không quản lý đúng cách vòng đời của dữ liệu này thì dữ liệu có thể được chia sẻ không chính xác hoặc bị mất giữa các lệnh gọi, dẫn đến lỗi logic hoặc lỗ hổng bảo mật. Xem xét rằng dữ liệu số dư hoặc trợ cấp tương tự như dự án Token không thể được lưu trữ chính xác, điều này sẽ dẫn đến sai sót trong logic hợp đồng và gây ra tổn thất. Hoặc sử dụng opcode này khi thiết lập địa chỉ chủ sở hữu sẽ khiến địa chỉ đặc quyền không được ghi chính xác và do đó làm mất khả năng 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 bộ nhớ tạm thời để tạm thời ghi lại giá giao dịch trên một sàn giao dịch 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 tính năng lưu trữ tạm thời sẽ tự động bị xóa khi kết thúc giao dịch thì người dùng có thể nhận được giao dịch không chính xác 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. giao dịch.giá cả. Điều này không chỉ có thể 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ể được sử dụng với mục đích xấu, ảnh hưởng đến độ tin cậy của nền tảng và tính bảo mật tài sản của người dùng.
EIP-6780
Đề xuất này thay đổi hành vi của opcode tự hủy trước đó, không hủy hợp đồng, chỉ chuyển mã thông báo và chỉ các hợp đồng được tạo trong cùng giao dịch với tự hủy mới bị hủy. Tác động của EIP này là tương đối lớn.
Sử dụng tạo 2 để triển khai lại hợp đồng tại cùng địa chỉ để nâng cấp hợp đồng. Tính năng này không còn được hỗ trợ, thay vào đó nên sử dụng ERC-2535 hoặc một loại hợp đồng proxy khác. (Điều này có thể ảnh hưởng đến việc sử dụng tạo 2 để thực hiện các hợp đồng có thể nâng cấp.Hợp đồng trên chuỗibảo vệ)
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 để hủy ether và gửi ether bị phá hủy vào hợp đồng. Nhưng hợp đồng chỉ có thể là hợp đồng được tạo ra trong cùng một giao dịch (hợp đồng được tạo ra bởi hợp đồng này hoặc các hợp đồng khác trong cùng một giao dịch). Nếu không, sẽ chỉ chuyển ether mà không hủy hợp đồng (ví dụ: nếu nó tự hủy và người thụ hưởng là hợp đồng tự hủy, điều này sẽ không tạo ra bất kỳ thay đổi nào). Điều này sẽ ảnh hưởng đến mọi thứ dựa vào tính năng tự hủy để rút tiền hoặc các hoạt động khác.hợp đồng。
Mã thông báo Gas tương tự như Mã thông báo CHI 1 inch hoạt động bằng cách duy trì phần bù và luôn thực thi TẠO 2 hoặc TỰ CHỌN ở phần bù này. Sau bản cập nhật này, nếu hợp đồng ở mức bù hiện tại không tự hủy chính xác thì 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 các cuộc tấn công trực tiếp vào hợp đồng, nhưng sẽ làm hỏng tính logic thông thường của các hợp đồng được triển khai ban đầu dựa vào hoạt động tự hủy (các hợp đồng chỉ dựa vào việc tự hủy để chuyển tiền sẽ không bị ảnh hưởng. Nếu sau đó hoạt động phải yêu cầu tự hủy. Nếu hợp đồng bị xóa, nó sẽ bị ảnh hưởng), khiến hợp đồng hoạt động không mong muốn. Chỉ đối với hợp đồng và người dùng, nó có thể gây ra đình công hợp đồng, mất tiền và các mối nguy hiểm khác (đối với ví dụ ban đầu sử dụng create 2 để triển khai hợp đồng mới tại địa chỉ ban đầu, tự hủy hợp đồng gốc, hợp đồng đã nâng cấp không thể triển khai thành công nữa). Về lâu dài, việc sửa đổi chức năng của opcode có thể dẫn đến các vấn đề về tập trung hóa.
Ví dụ: có một vault hợp đồng vault hiện có cần cập nhật:
tạo 2 hợp đồng lưu trữ tạm thời được sử dụng để dự trữ tạm thời quỹ kho tiền.
Hợp đồng vault tự hủy, tiền chuyển sang hợp đồng tạm thời (chỉ chuyển tiền mà không hủy hợp đồng)
Tạo 2 hợp đồng vault mới tại địa chỉ ban đầu (không thành công vì hợp đồng vault ban đầu chưa bị hủy)
Hợp đồng tạm thời tự hủy sẽ trả lại tiền vào vault (tiền bị mất, hợp đồng vault 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 mang lại rủi ro cho những thay đổi đối với lớp hợp đồng thông minh cốt 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 mà chúng có thể gây ra cũng cần được chú ý nhiều. Bạn có thể làm điều này vớiSalusLiên hệ để xem xét rủi ro hoặc hỗ trợ kiểm toán hoặc đọc thêm để tìm hiểu về những thay đổi.
IOS
Android