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

Mạng chính sẽ được kích hoạt vào ngày 13 tháng 3. Bản nâng cấp Cancun sẽ mang lại những rủi ro và vấn đề bảo mật tiềm ẩn nào?

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

Bản nâng cấp Cancun dự kiến sẽ được kích hoạt trên mạng chính Ethereum vào ngày 13 tháng 3. Bài viết này đã tổng hợp các biện pháp phòng ngừa 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.

Nguồn gốc: salus security

Chuyện dài: Bản nâng cấp Cancun đang đến gần. Bản nâng cấp này chủ yếu bao gồm các thay đổi về lớp thực thi do sáu EIP, EIP-1153 đề xuất , 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.

Đánh giá đề xuất EIP

1.EIP-1153

EIP-1153 giới thiệu các opcode 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.

2.EIP-4788

EIP-4788 nhằm mục đích chuyển đổi khối chuỗi beacon The rễ cây băm được tiếp xúc với EVM để cho phép truy cập vào các rễ này trong 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.

3.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 Sharded Blob" đượ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 hoạt động bằng cách giới thiệu "các giao dịch mang blob" chứa lượng lớn dữ liệu mà việc thực thi EVM không thể truy cập được nhưng có thể truy cập các cam kết 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 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.

4.EIP-5656

EIP-5656 giới thiệu lệnh EVM mới MCOPY để sao chép các vùng bộ nhớ một cách hiệu quả. Đề 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ớ.

5.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.

6.EIP-7516

EIP-7516 giới thiệu hướng dẫn EVM mới BLOBBASEFEE , được sử dụng để 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.

Các cân nhắc về bảo mật được tiết lộ chính thức

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 về băng thông trên mỗi khối đèn hiệu lên tới Giới thiệu 0,75 MB. 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 (30M Gas / 16 Gas trên mỗi byte dữ liệu cuộc gọi = 1,875M 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 vẫn 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ì không cần kết hợp lưu trữ blob với tải thực thi Chỉ cần dài. Đ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, 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ớ, bởi vì việc mở rộng bộ nhớ tuân theo quy trình quy định về giá giống nhau.

EIP-6780

Ứng dụng sau đây SELFDESTRUCT sẽ bị hỏng và theo cách này, các Ứng dụng sẽ bị hỏng việc sử dụng nó không còn an toàn nữa:

Trong đóCREATE2 được sử dụng để triển khai lại hợp đồng ở cùng một vị trí nhằm 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

EIP1153

Hãy tưởng tượng 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 lệnh gọi tới 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 và dữ liệu sẽ được giải phóng sau khi thực hiện giao dịch. Hợp đồng bằng văn bản thì không ghi vĩnh viễn như store. 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 vòng đời của các biến lưu trữ tạm thời, điều này 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 phá hủy hợp đồng, chỉ chuyển Token, chỉ những hợp đồng được tạo trong cùng giao dịch 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 create2 để triển khai lại hợp đồng tại cùng địa chỉ nhằm nâng cấp hợp đồng. 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. (Điều này có thể ảnh hưởng đến tính bảo mật của các hợp đồng trên chuỗi sử dụng create2 để thực hiện các hợp đồng có thể nâng cấp)

Hoạt động SELFDESTRUCT trong hợp đồng thông minh cho phép hợp đồng bị hủy và hợp đồng Số dư đượ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 tất cả các hợp đồng dựa vào tính năng tự hủy để rút tiền hoặc các hoạt động khác.

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ì mức chênh lệch và luôn thực thi CREATE2 hoặc SELFDESTRUCT ở mức chênh lệch 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ì CREATE2 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 hợp đồng được triển khai ban đầu dựa vào hoạt động tự hủy ( chỉ dựa vào việc tự hủy) Hợp đồng chuyển tiền sẽ không bị ảnh hưởng, nếu thao tác tiếp theo phải yêu cầu xóa hợp đồng tự hủy thì sẽ bị ảnh hưởng), khiến hợp đồng hoạt động ngoài dự kiến. Chỉ dành cho hợp đồng và người dùng, nó có thể khiến hợp đồng bị đình công, mất tiền và các mối nguy hiểm khác. (Ví dụ: hợp đồng ban đầu sử dụng create2 để triển khai hợp đồng mới tại địa chỉ ban đầu và tự hủy hợp đồng ban đầu để nâng cấp không thể triển khai được nữa thành công). 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ụ: nếu có một hợp đồng vault hiện có cần cập nhật:

● ; hợp đồng lưu trữ tạm thờicreate2 được sử dụng để dự trữ tạm thời quỹ kho tiền

● Tự hủy hợp đồng kho tiền và tiền được chuyển đến hợp đồng tạm thời (chỉ chuyển tiền nhưng không hủy hợp đồng)

● Tạo2 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 kho tiền (tiền bị mất, hợp đồng kho tiền không được tạo)

Đọc mở rộng

Bản 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ể liên hệ với Salus để được hỗ trợ đánh giá rủi ro hoặc kiểm toán hoặc đọc thêm để tìm hiểu về những thay đổi.

Thông số kỹ thuật nâng cấp mạng Cancun