Kiểm Tra An Ninh Cần Thiết Cho Nhà Phát Triển Trước Khi Nâng Cấp Cancun

Nâng cao3/7/2024, 5:10:08 AM
Bài viết này bao gồm các thay đổi chính được đề xuất bởi sáu EIP cho nâng cấp Cancun, bao gồm EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780 và EIP-7516. EIP-4844, trọng tâm của bản nâng cấp này, nhằm tăng cường tính mở rộng của Ethereum, giảm chi phí giao dịch và tăng tốc độ giao dịch cho các giải pháp Layer 2. Nâng cấp Cancun đã được thử nghiệm thành công trên các mạng thử nghiệm Ethereum Goerli, Sepolia và Holesky vào ngày 17 tháng 1, 30 tháng 1 và 7 tháng 2, tương ứng, với kế hoạch kích hoạt vào ngày 13 tháng 3 trên mạng chính Ethereum.

*Chuyển Tiêu Đề Gốc: Các Điều Kiện Kiểm Tra An Toàn Mà Nhà Phát Triển Dự Án Cần Xem Trước Khi Cập Nhật Cancun

Tóm tắt: Với bản nâng cấp Cancun đang đến gần, nó bao gồm sáu thay đổi được đề xuất bởi EIP, chủ yếu là EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780 và EIP-7516. EIP-4844 tập trung vào việc 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 các giải pháp Layer 2. Bản nâng cấp đã được thử nghiệm trên Ethereum testnets và được lên lịch kích hoạt trên mainnet vào ngày 13 tháng 3. Salus đã biên soạn những yếu tố an ninh quan trọng mà các nhà phát triển cần kiểm tra trước khi bản nâng cấp.

Đánh giá các Đề xuất EIP

Xem xét An ninh Chính thức

Rủi ro liên quan đến hợp đồng thông minh

Đọc thêm

Đánh giá các Đề xuất EIP

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 một cách tương tự như lưu trữ, nhưng với lưu trữ tạm thời bị loại bỏ sau mỗi giao dịch. Điều này có nghĩa là lưu trữ tạm thời không giải mã các giá trị từ lưu trữ, cũng không mã hóa các giá trị vào lưu trữ, dẫn đến chi phí thấp hơn do tránh truy cập đĩa. Với việc giới thiệu hai opcode mới, TLOAD và TSTORE (nơi “T” đứng cho “tạm thời”), hợp đồng thông minh có thể truy cập lưu trữ tạm thời. Đề xuất này nhằm cung cấp một giải pháp dành riêng và hiệu quả cho việc giao tiếp giữa các khung thực thi lồng nhau nhiều lớp trong quá trình thực thi giao dịch trên Ethereum.

EIP-4788

EIP-4788 nhằm mục đích tiết lộ các rễ cây băm của các khối của beacon chain cho EVM, cho phép các rễ này được truy cập trong các hợp đồng thông minh. Điều này cho phép truy cập vào trạng thái tầng đồng thuận mà không cần tin cậy, hỗ trợ các trường hợp sử dụng khác nhau như các hồ bơi đặt cược, cấu trúc đặt cược lại, cầu nối hợp đồng thông minh và giảm thiểu MEV. Đề xuất đạt được điều này bằng cách lưu trữ các rễ này trong một hợp đồng thông minh và sử dụng một bộ đệm tròn để giới hạn việc tiêu thụ bộ nhớ, đảm bảo rằng mỗi khối thực thi chỉ cần không gian hằng số để biểu diễ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 Shard Blob” được thiết kế để mở rộng khả năng sẵn có dữ liệu của Ethereum một cách đơn giản và tương thích ngược. Đề xuất này đạt được mục tiêu của mình bằng cách giới thiệu “giao dịch mang theo blob” chứa lượng dữ liệu lớn mà không thể truy cập bởi EVM nhưng có thể truy cập bởi cam kết của chúng. Định dạng này hoàn toàn tương thích với định dạng được sử dụng bởi full-sharding tương lai, cung cấp một sự giảm nhẹ tạm thời nhưng đáng kể cho tính mở rộng của rollup.

EIP-5656

EIP-5656 giới thiệu một hướng dẫn EVM mới, MCOPY, để sao chép hiệu quả các khu vực bộ nhớ. Đề xuất này nhằm giảm thiểu chi phí vận hành của 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ớ bằng cách sử dụng hướng dẫn MCOPY. MCOPY cho phép chồng lên địa chỉ nguồn và đích, được thiết kế với sự tương thích ngược và nhằm cải thiện hiệu suất thực thi trong các tình huống khác nhau, bao gồm xây dựng cấu trúc dữ liệu, truy cập hiệu quả và sao chép các đối tượng bộ nhớ.

EIP-6780

EIP-6780 sửa đổi chức năng của mã opcode SELFDESTRUCT. Trong đề xuất này, SELFDESTRUCT chỉ xóa các tài khoản và chuyển toàn bộ ether trong cùng một giao dịch như việc tạo hợp đồng. Ngoài ra, khi thực thi SELFDESTRUCT, hợp đồng sẽ không bị xóa mà sẽ chuyển toàn bộ ether đến một mục tiêu cụ thể. Thay đổi này đáp ứng việc sử dụng tương lai của cây Verkle, nhằm mục tiêu đơn giản hóa việc triển khai EVM, giảm độ phức tạp của các thay đổi trạng thái, trong khi vẫn giữ lại một số trường hợp sử dụng phổ biến của SELFDESTRUCT.

EIP-7516

EIP-7516 giới thiệu một hướng dẫn EVM mới, BLOBBASEFEE, để trả về giá trị cơ bản cho blobs trong quá trình thực thi khối hiện tại. Hướng dẫn này tương tự như opcode BASEFEE được giới thiệu trong EIP-3198, với sự khác biệt là nó trả về phí cơ bản của blob được xác định theo EIP-4844. Chức năng này cho phép các hợp đồng xem xét mức giá gas của dữ liệu blob theo cách lập trình, cho phép các hợp đồng rollup tính toán chi phí sử dụng dữ liệu blob mà không cần tin cậy hoặc thực hiện tương lai gas của blob để làm mịn chi phí dữ liệu blob.

Xem xét an ninh chính thức

EIP-1153

Nhà phát triển hợp đồng thông minh nên hiểu về vòng đời của các biến lưu trữ tạm thời trước khi sử dụng chúng. Khi bộ nhớ tạm thời được tự động xóa khi giao dịch kết thúc, nhà phát triển hợp đồng thông minh có thể cố gắng tránh việc xóa khe cắm trong lúc gọi để tiết kiệm gas. Tuy nhiên, điều này có thể ngăn chặn việc 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 tái nhập) hoặc dẫn đến lỗi khác. Do đó, nhà phát triển hợp đồng thông minh nên cẩn thận và chỉ giữ các giá trị khác không là không khi khe lưu trữ tạm thời được dành cho các cuộc gọi trong cùng một giao dịch. Nếu không, hành vi của các opcode này giống như SLOAD và SSTORE, do đó tất cả các quan điểm về an ninh phổ biến đều áp dụng, đặc biệt là về các rủi ro tái nhập.

Nhà phát triển hợp đồng thông minh cũng có thể cố gắng sử dụng bộ nhớ tạm thời như một phương án thay thế cho bộ ánh xạ bộ nhớ. Họ cần nhận thức rằng bộ nhớ tạm thời không bị loại bỏ như bộ nhớ khi một cuộc gọi trả về hoặc bị quay trở lại và nên ưu tiên bộ nhớ trong những trường hợp sử dụng như vậy để tránh hành vi không mong muốn trong quá trình tái nhập trong giao dịch tương tự. Chi phí cao của bộ nhớ tạm thời nên đã không khuyến khích mô hình sử dụng này. Hầu hết các trường hợp sử dụng cho ánh xạ trong bộ nhớ có thể được triển khai tốt hơn thông qua một danh sách sắp xếp các mục theo khóa, và bộ nhớ tạm thời trong ánh xạ bộ nhớ hiếm khi cần thiết trong hợp đồng thông minh (tức là, không có trường hợp sử dụng đã biết trong sản xuất).

EIP-4844

EIP này tăng nhu cầu băng thông cho mỗi khối đèn hiệu lên đến khoảng 0,75 MB. Điều này tăng khoảng 40% so với kích thước tối đa lý thuyết của các khối hiện nay (30M Gas / 16 Gas trên mỗi byte calldata = 1,875M byte), vì vậy nó không tăng đáng kể băng thông trong các tình huống xấu nhất. Sau khi hợp nhất, thời gian khối là cố định thay vì phân phối Poisson không thể dự đoán, cung cấp khung thời gian đảm bảo cho sự lan truyền của các khối lớn.

Ngay cả khi dữ liệu gọi bị hạn chế, tải trọng duy trì của EIP này đáng kể thấp hơn so với các giải pháp thay thế có thể giảm chi phí của dữ liệu gọi vì lưu trữ Blob không cần được giữ trong cùng thời gian như tải trọng thực thi. Điều này làm cho việc triển khai các chiến lược yêu cầu các blob này phải được giữ ít nhất trong một khoảng thời gian trở lên. Giá trị cụ thể được chọn là MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS epoch, khoảng 18 ngày, ngắn hơn nhiều so với thời gian quay vòng một năm được đề xuất (nhưng chưa được triển khai) cho lịch sử tải trọng hợp lệ.

EIP-5656

Khách hàng nên chú ý rằng các triển khai của họ không sử dụng bộ đệm trung gian (ví dụ, hàm memmove trong C stdlib không sử dụng bộ đệm trung gian) vì đây là một vector tấn công từ chối dịch vụ (DoS) tiềm năng. Hầu hết các hàm tích hợp ngôn ngữ/hàm thư viện tiêu chuẩn được sử dụng để di chuyển byte có các đặc điểm hiệu suất đúng ở đây.

Ngoài ra, phân tích về các cuộc tấn công từ chối dịch vụ (DoS) và tấn công kiếm soát bộ nhớ cũng giới như với các opcode chạm vào bộ nhớ khác vì mội một mộ rộng theo các quy tếnh giá tương tự.

EIP-6780

Các ứng dụng SELFDESTRUCT sau đây 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:

CREATE2 được sử dụng để triển khai lại một hợp đồng tại cùng một vị trí để làm cho các hợp đồng có thể nâng cấp. Chức năng này không còn được hỗ trợ và nên được thay thế bằng ERC-2535 hoặc các loại hợp đồng proxy khác.

Nếu một hợp đồng phụ thuộc vào việc đốt ether cho một hợp đồng thông qua SELFDESTRUCT như là người hưởng lợi, thì hợp đồng không được tạo ra trong cùng giao dịch đó.

Rủi ro liên quan đến Hợp đồng Thông minh

EIP1153

Xem xét hai kịch bản sử dụng các opcode TLOAD và TSTORE:

  1. Gọi hợp đồng sử dụng những mã opcode này.
  2. Gọi hợp đồng sử dụng các mã opcode này.

Rủi ro 1:

So với SSTORE và SLOAD truyền thống, việc giới thiệu lưu trữ tạm thờ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 thông qua TLOAD và sẽ được giải phóng sau khi thực hiện giao dịch, thay vì được ghi lại một cách vĩnh viễn trong hợp đồng như SSTORE. Các nhà phát triển nên hiểu rõ các đặc điểm của các opcode này khi sử dụng chúng để tránh sử dụng một cách không chính xác, điều này có thể dẫn đến việc dữ liệu không được ghi chính xác vào hợp đồng, gây ra tổn thất. Ngoài ra, dữ liệu được lưu trữ bởi TSTORE là riêng tư và chỉ có thể được truy cập bởi hợp đồng chính nó. Nếu việc truy cập bên ngoài đến dữ liệu này cần thiết, nó phải được truyền qua tham số hoặc được lưu trữ tạm thời trong một biến lưu trữ công khai.

Risk 2:

Một rủi ro tiềm năng khác là nếu nhà phát triển hợp đồng thông minh không quản lý vòng đời của các biến lưu trữ tạm thời một cách chính xác, có thể dẫn đến dữ liệu bị xóa vào thời điểm không thích hợp hoặc được giữ không đúng cách. Nếu một hợp đồng mong đợi sử dụng dữ liệu được lưu trữ trong bộ nhớ tạm thời trong các cuộc gọi tiếp theo của giao dịch nhưng không quản lý đúng vòng đời của dữ liệu này, có thể một cách sai lầm chia sẻ hoặc mất dữ liệu giữa các cuộc gọi khác nhau, dẫn đến lỗi logic hoặc lỗ hổng bảo mật. Việc không lưu trữ dữ liệu một cách chính xác, chẳng hạn dữ liệu số dư hoặc phép ước trong các dự án token, có thể dẫn đến lỗi logic trong hợp đồng, gây thiệt hại. Tương tự, việc sử dụng các mã opcode này để thiết lập địa chỉ chủ sở hữu có thể dẫn đến địa chỉ ưu tiên không được ghi đúng cách, dẫn đến việc mất mạng các thay đổi cho các thông số quan trọng của hợp đồng.

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 một nền tảng giao dịch tiền điện tử. Hợp đồng cập nhật giá sau mỗi giao dịch 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 xem xét việc tự động xóa lưu trữ tạm thời vào cuối một giao dịch, có thể có một khoảng thời gian giữa cuối một giao dịch và bắt đầu giao dịch tiếp theo nơi người dùng có thể nhận được một giá không chính xác hoặc lỗi thời. Điều này không chỉ dẫn đến người dùng ra quyết định dựa trên thông tin không chính xác mà còn có thể bị lợi dụng một cách độc hại, ảnh hưởng đến danh tiếng của nền tảng và an ninh của tài sản của người dùng.

EIP-6780

Đề xuất này thay đổi hành vi của mã opcode selfdestruct trước đó, nơi hợp đồng không bị đốt cháy mà chỉ xảy ra chuyển giao token, và chỉ những hợp đồng được tạo ra trong cùng giao dịch với hợp đồng selfdestruct mới bị đốt cháy. Tác động của EIP này khá quan trọng.

Sử dụng create2 để triển khai lại hợp đồng tại cùng địa chỉ cho việc nâng cấp hợp đồng không còn được hỗ trợ nữa. Chức năng này nên được thay thế bằng ERC-2535 hoặc các 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ủahợp đồng trên chuỗithực hiện hợp đồng có thể nâng cấp bằng cách sử dụng create2).

Hoạt động SELFDESTRUCT trong hợp đồng thông minh cho phép hợp đồng bị đốt cháy, và số dư hợp đồng được gửi đến một địa chỉ mục tiêu cụ thể. Trong trường hợp này, hợp đồng sử dụng SELFDESTRUCT để đốt Ether và gửi Ether đã đốt đến hợp đồng. Tuy nhiên, hợp đồng này chỉ được tạo trong cùng một giao dịch như các hợp đồng khác (hợp đồng được tạo 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, Ether sẽ chỉ được chuyển mà không đốt cháy hợp đồng (ví dụ, selfdestruct với người hưởng là hợp đồng selfdestruct, đ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ả hợp đồngcác hàm tựhủy lấy thụyït quyền cho các yêu cầu rút tiền hoặc các hoạt động khác.

Một Gas Token tương tự như 1inch CHI Token hoạt động như sau: duy trì một offset, luôn triển khai CREATE2 hoặc SELFDESTRUCT tại offset này. Sau cập nhật này, nếu hợp đồng tại offset hiện tại không được phá hủy đúng cách, các CREATE2 tiếp theo sẽ không thể triển khai hợp đồng thành công.

Đề xuất triển khai này không thể tấn công trực tiếp vào các hợp đồng, nhưng nó sẽ gây hỏng logic bình thường của các hợp đồng hiện tại phụ thuộc vào các hoạt động selfdestruct (các hợp đồng chỉ phụ thuộc vào selfdestruct để chuyển quỹ không bị ảnh hưởng, nhưng các hợp đồng yêu cầu các hoạt động sau đó để xóa các hợp đồng selfdestruct bị ảnh hưởng), gây ra các hợp đồng hoạt động một cách không mong muốn, và có thể dẫn đến các vấn đề như đình công hợp đồng, mất quỹ, v.v. (ví dụ, các hợp đồng mà ban đầu sử dụng create2 để triển khai các 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 thành công nữa). Trong tương lai, việc sửa đổi chức năng của một opcode có thể mang lại các vấn đề tập trung.

Ví dụ, có một hợp đồng két đang tồn tại để cập nhật:

  • Hợp đồng lưu trữ tạm thời, create2, được sử dụng để tạm thời dự trữ tiền cho ngăn két.
  • Tự hủy hợp đồng két, chuyển tiền vào hợp đồng tạm thời (chỉ chuyển tiền mà không đốt hợp đồng).
  • Tạo một hợp đồng két mới tại địa chỉ ban đầu bằng cách sử dụng create2 (thất bại vì hợp đồng két ban đầu chưa được đốt cháy).
  • Tự hủy hợp đồng tạm thời để trả lại tiền vào két (tiền bị mất, hợp đồng két chưa được tạo ra).

Đọ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, những thay đổi đối với lớp hợp đồng thông minh cốt lõi trong bản nâng cấp này mang lại rủi ro 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 tiềm ẩn mà chúng có thể mang lại cần được theo dõi 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 đọc thêm để hiểu những thay đổi.

Cancun Network Upgrade Specification

EIP-1153

EIP-4788

EIP-4844

EIP-5656

EIP-6780

EIP-7516

Hợp đồng Metapod

Hợp đồng GasToken2

Disclaimer:

  1. Bài viết này được sao chép từ [Aicoin]Chuyển tiếp Tiêu đề Gốc ‘Salus Insights: Điều cần thiết mà các nhà phát triển dự án cần xem trước khi nâng cấp Cancun. Bản quyền thuộc về tác giả gốc [‘*Odaily Planet hàng ngày]. Nếu có ý kiến ​​phản đối về việc tái in này, vui lòng liên hệ Gate Learnđội, và họ sẽ xử lý nhanh chóng.
  2. Tuyên bố từ chối 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 cấu thành bất kỳ lời khuyên đầu tư nào.
  3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được nêu ra, 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.

Kiểm Tra An Ninh Cần Thiết Cho Nhà Phát Triển Trước Khi Nâng Cấp Cancun

Nâng cao3/7/2024, 5:10:08 AM
Bài viết này bao gồm các thay đổi chính được đề xuất bởi sáu EIP cho nâng cấp Cancun, bao gồm EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780 và EIP-7516. EIP-4844, trọng tâm của bản nâng cấp này, nhằm tăng cường tính mở rộng của Ethereum, giảm chi phí giao dịch và tăng tốc độ giao dịch cho các giải pháp Layer 2. Nâng cấp Cancun đã được thử nghiệm thành công trên các mạng thử nghiệm Ethereum Goerli, Sepolia và Holesky vào ngày 17 tháng 1, 30 tháng 1 và 7 tháng 2, tương ứng, với kế hoạch kích hoạt vào ngày 13 tháng 3 trên mạng chính Ethereum.

*Chuyển Tiêu Đề Gốc: Các Điều Kiện Kiểm Tra An Toàn Mà Nhà Phát Triển Dự Án Cần Xem Trước Khi Cập Nhật Cancun

Tóm tắt: Với bản nâng cấp Cancun đang đến gần, nó bao gồm sáu thay đổi được đề xuất bởi EIP, chủ yếu là EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780 và EIP-7516. EIP-4844 tập trung vào việc 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 các giải pháp Layer 2. Bản nâng cấp đã được thử nghiệm trên Ethereum testnets và được lên lịch kích hoạt trên mainnet vào ngày 13 tháng 3. Salus đã biên soạn những yếu tố an ninh quan trọng mà các nhà phát triển cần kiểm tra trước khi bản nâng cấp.

Đánh giá các Đề xuất EIP

Xem xét An ninh Chính thức

Rủi ro liên quan đến hợp đồng thông minh

Đọc thêm

Đánh giá các Đề xuất EIP

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 một cách tương tự như lưu trữ, nhưng với lưu trữ tạm thời bị loại bỏ sau mỗi giao dịch. Điều này có nghĩa là lưu trữ tạm thời không giải mã các giá trị từ lưu trữ, cũng không mã hóa các giá trị vào lưu trữ, dẫn đến chi phí thấp hơn do tránh truy cập đĩa. Với việc giới thiệu hai opcode mới, TLOAD và TSTORE (nơi “T” đứng cho “tạm thời”), hợp đồng thông minh có thể truy cập lưu trữ tạm thời. Đề xuất này nhằm cung cấp một giải pháp dành riêng và hiệu quả cho việc giao tiếp giữa các khung thực thi lồng nhau nhiều lớp trong quá trình thực thi giao dịch trên Ethereum.

EIP-4788

EIP-4788 nhằm mục đích tiết lộ các rễ cây băm của các khối của beacon chain cho EVM, cho phép các rễ này được truy cập trong các hợp đồng thông minh. Điều này cho phép truy cập vào trạng thái tầng đồng thuận mà không cần tin cậy, hỗ trợ các trường hợp sử dụng khác nhau như các hồ bơi đặt cược, cấu trúc đặt cược lại, cầu nối hợp đồng thông minh và giảm thiểu MEV. Đề xuất đạt được điều này bằng cách lưu trữ các rễ này trong một hợp đồng thông minh và sử dụng một bộ đệm tròn để giới hạn việc tiêu thụ bộ nhớ, đảm bảo rằng mỗi khối thực thi chỉ cần không gian hằng số để biểu diễ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 Shard Blob” được thiết kế để mở rộng khả năng sẵn có dữ liệu của Ethereum một cách đơn giản và tương thích ngược. Đề xuất này đạt được mục tiêu của mình bằng cách giới thiệu “giao dịch mang theo blob” chứa lượng dữ liệu lớn mà không thể truy cập bởi EVM nhưng có thể truy cập bởi cam kết của chúng. Định dạng này hoàn toàn tương thích với định dạng được sử dụng bởi full-sharding tương lai, cung cấp một sự giảm nhẹ tạm thời nhưng đáng kể cho tính mở rộng của rollup.

EIP-5656

EIP-5656 giới thiệu một hướng dẫn EVM mới, MCOPY, để sao chép hiệu quả các khu vực bộ nhớ. Đề xuất này nhằm giảm thiểu chi phí vận hành của 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ớ bằng cách sử dụng hướng dẫn MCOPY. MCOPY cho phép chồng lên địa chỉ nguồn và đích, được thiết kế với sự tương thích ngược và nhằm cải thiện hiệu suất thực thi trong các tình huống khác nhau, bao gồm xây dựng cấu trúc dữ liệu, truy cập hiệu quả và sao chép các đối tượng bộ nhớ.

EIP-6780

EIP-6780 sửa đổi chức năng của mã opcode SELFDESTRUCT. Trong đề xuất này, SELFDESTRUCT chỉ xóa các tài khoản và chuyển toàn bộ ether trong cùng một giao dịch như việc tạo hợp đồng. Ngoài ra, khi thực thi SELFDESTRUCT, hợp đồng sẽ không bị xóa mà sẽ chuyển toàn bộ ether đến một mục tiêu cụ thể. Thay đổi này đáp ứng việc sử dụng tương lai của cây Verkle, nhằm mục tiêu đơn giản hóa việc triển khai EVM, giảm độ phức tạp của các thay đổi trạng thái, trong khi vẫn giữ lại một số trường hợp sử dụng phổ biến của SELFDESTRUCT.

EIP-7516

EIP-7516 giới thiệu một hướng dẫn EVM mới, BLOBBASEFEE, để trả về giá trị cơ bản cho blobs trong quá trình thực thi khối hiện tại. Hướng dẫn này tương tự như opcode BASEFEE được giới thiệu trong EIP-3198, với sự khác biệt là nó trả về phí cơ bản của blob được xác định theo EIP-4844. Chức năng này cho phép các hợp đồng xem xét mức giá gas của dữ liệu blob theo cách lập trình, cho phép các hợp đồng rollup tính toán chi phí sử dụng dữ liệu blob mà không cần tin cậy hoặc thực hiện tương lai gas của blob để làm mịn chi phí dữ liệu blob.

Xem xét an ninh chính thức

EIP-1153

Nhà phát triển hợp đồng thông minh nên hiểu về vòng đời của các biến lưu trữ tạm thời trước khi sử dụng chúng. Khi bộ nhớ tạm thời được tự động xóa khi giao dịch kết thúc, nhà phát triển hợp đồng thông minh có thể cố gắng tránh việc xóa khe cắm trong lúc gọi để tiết kiệm gas. Tuy nhiên, điều này có thể ngăn chặn việc 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 tái nhập) hoặc dẫn đến lỗi khác. Do đó, nhà phát triển hợp đồng thông minh nên cẩn thận và chỉ giữ các giá trị khác không là không khi khe lưu trữ tạm thời được dành cho các cuộc gọi trong cùng một giao dịch. Nếu không, hành vi của các opcode này giống như SLOAD và SSTORE, do đó tất cả các quan điểm về an ninh phổ biến đều áp dụng, đặc biệt là về các rủi ro tái nhập.

Nhà phát triển hợp đồng thông minh cũng có thể cố gắng sử dụng bộ nhớ tạm thời như một phương án thay thế cho bộ ánh xạ bộ nhớ. Họ cần nhận thức rằng bộ nhớ tạm thời không bị loại bỏ như bộ nhớ khi một cuộc gọi trả về hoặc bị quay trở lại và nên ưu tiên bộ nhớ trong những trường hợp sử dụng như vậy để tránh hành vi không mong muốn trong quá trình tái nhập trong giao dịch tương tự. Chi phí cao của bộ nhớ tạm thời nên đã không khuyến khích mô hình sử dụng này. Hầu hết các trường hợp sử dụng cho ánh xạ trong bộ nhớ có thể được triển khai tốt hơn thông qua một danh sách sắp xếp các mục theo khóa, và bộ nhớ tạm thời trong ánh xạ bộ nhớ hiếm khi cần thiết trong hợp đồng thông minh (tức là, không có trường hợp sử dụng đã biết trong sản xuất).

EIP-4844

EIP này tăng nhu cầu băng thông cho mỗi khối đèn hiệu lên đến khoảng 0,75 MB. Điều này tăng khoảng 40% so với kích thước tối đa lý thuyết của các khối hiện nay (30M Gas / 16 Gas trên mỗi byte calldata = 1,875M byte), vì vậy nó không tăng đáng kể băng thông trong các tình huống xấu nhất. Sau khi hợp nhất, thời gian khối là cố định thay vì phân phối Poisson không thể dự đoán, cung cấp khung thời gian đảm bảo cho sự lan truyền của các khối lớn.

Ngay cả khi dữ liệu gọi bị hạn chế, tải trọng duy trì của EIP này đáng kể thấp hơn so với các giải pháp thay thế có thể giảm chi phí của dữ liệu gọi vì lưu trữ Blob không cần được giữ trong cùng thời gian như tải trọng thực thi. Điều này làm cho việc triển khai các chiến lược yêu cầu các blob này phải được giữ ít nhất trong một khoảng thời gian trở lên. Giá trị cụ thể được chọn là MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS epoch, khoảng 18 ngày, ngắn hơn nhiều so với thời gian quay vòng một năm được đề xuất (nhưng chưa được triển khai) cho lịch sử tải trọng hợp lệ.

EIP-5656

Khách hàng nên chú ý rằng các triển khai của họ không sử dụng bộ đệm trung gian (ví dụ, hàm memmove trong C stdlib không sử dụng bộ đệm trung gian) vì đây là một vector tấn công từ chối dịch vụ (DoS) tiềm năng. Hầu hết các hàm tích hợp ngôn ngữ/hàm thư viện tiêu chuẩn được sử dụng để di chuyển byte có các đặc điểm hiệu suất đúng ở đây.

Ngoài ra, phân tích về các cuộc tấn công từ chối dịch vụ (DoS) và tấn công kiếm soát bộ nhớ cũng giới như với các opcode chạm vào bộ nhớ khác vì mội một mộ rộng theo các quy tếnh giá tương tự.

EIP-6780

Các ứng dụng SELFDESTRUCT sau đây 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:

CREATE2 được sử dụng để triển khai lại một hợp đồng tại cùng một vị trí để làm cho các hợp đồng có thể nâng cấp. Chức năng này không còn được hỗ trợ và nên được thay thế bằng ERC-2535 hoặc các loại hợp đồng proxy khác.

Nếu một hợp đồng phụ thuộc vào việc đốt ether cho một hợp đồng thông qua SELFDESTRUCT như là người hưởng lợi, thì hợp đồng không được tạo ra trong cùng giao dịch đó.

Rủi ro liên quan đến Hợp đồng Thông minh

EIP1153

Xem xét hai kịch bản sử dụng các opcode TLOAD và TSTORE:

  1. Gọi hợp đồng sử dụng những mã opcode này.
  2. Gọi hợp đồng sử dụng các mã opcode này.

Rủi ro 1:

So với SSTORE và SLOAD truyền thống, việc giới thiệu lưu trữ tạm thờ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 thông qua TLOAD và sẽ được giải phóng sau khi thực hiện giao dịch, thay vì được ghi lại một cách vĩnh viễn trong hợp đồng như SSTORE. Các nhà phát triển nên hiểu rõ các đặc điểm của các opcode này khi sử dụng chúng để tránh sử dụng một cách không chính xác, điều này có thể dẫn đến việc dữ liệu không được ghi chính xác vào hợp đồng, gây ra tổn thất. Ngoài ra, dữ liệu được lưu trữ bởi TSTORE là riêng tư và chỉ có thể được truy cập bởi hợp đồng chính nó. Nếu việc truy cập bên ngoài đến dữ liệu này cần thiết, nó phải được truyền qua tham số hoặc được lưu trữ tạm thời trong một biến lưu trữ công khai.

Risk 2:

Một rủi ro tiềm năng khác là nếu nhà phát triển hợp đồng thông minh không quản lý vòng đời của các biến lưu trữ tạm thời một cách chính xác, có thể dẫn đến dữ liệu bị xóa vào thời điểm không thích hợp hoặc được giữ không đúng cách. Nếu một hợp đồng mong đợi sử dụng dữ liệu được lưu trữ trong bộ nhớ tạm thời trong các cuộc gọi tiếp theo của giao dịch nhưng không quản lý đúng vòng đời của dữ liệu này, có thể một cách sai lầm chia sẻ hoặc mất dữ liệu giữa các cuộc gọi khác nhau, dẫn đến lỗi logic hoặc lỗ hổng bảo mật. Việc không lưu trữ dữ liệu một cách chính xác, chẳng hạn dữ liệu số dư hoặc phép ước trong các dự án token, có thể dẫn đến lỗi logic trong hợp đồng, gây thiệt hại. Tương tự, việc sử dụng các mã opcode này để thiết lập địa chỉ chủ sở hữu có thể dẫn đến địa chỉ ưu tiên không được ghi đúng cách, dẫn đến việc mất mạng các thay đổi cho các thông số quan trọng của hợp đồng.

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 một nền tảng giao dịch tiền điện tử. Hợp đồng cập nhật giá sau mỗi giao dịch 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 xem xét việc tự động xóa lưu trữ tạm thời vào cuối một giao dịch, có thể có một khoảng thời gian giữa cuối một giao dịch và bắt đầu giao dịch tiếp theo nơi người dùng có thể nhận được một giá không chính xác hoặc lỗi thời. Điều này không chỉ dẫn đến người dùng ra quyết định dựa trên thông tin không chính xác mà còn có thể bị lợi dụng một cách độc hại, ảnh hưởng đến danh tiếng của nền tảng và an ninh của tài sản của người dùng.

EIP-6780

Đề xuất này thay đổi hành vi của mã opcode selfdestruct trước đó, nơi hợp đồng không bị đốt cháy mà chỉ xảy ra chuyển giao token, và chỉ những hợp đồng được tạo ra trong cùng giao dịch với hợp đồng selfdestruct mới bị đốt cháy. Tác động của EIP này khá quan trọng.

Sử dụng create2 để triển khai lại hợp đồng tại cùng địa chỉ cho việc nâng cấp hợp đồng không còn được hỗ trợ nữa. Chức năng này nên được thay thế bằng ERC-2535 hoặc các 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ủahợp đồng trên chuỗithực hiện hợp đồng có thể nâng cấp bằng cách sử dụng create2).

Hoạt động SELFDESTRUCT trong hợp đồng thông minh cho phép hợp đồng bị đốt cháy, và số dư hợp đồng được gửi đến một địa chỉ mục tiêu cụ thể. Trong trường hợp này, hợp đồng sử dụng SELFDESTRUCT để đốt Ether và gửi Ether đã đốt đến hợp đồng. Tuy nhiên, hợp đồng này chỉ được tạo trong cùng một giao dịch như các hợp đồng khác (hợp đồng được tạo 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, Ether sẽ chỉ được chuyển mà không đốt cháy hợp đồng (ví dụ, selfdestruct với người hưởng là hợp đồng selfdestruct, đ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ả hợp đồngcác hàm tựhủy lấy thụyït quyền cho các yêu cầu rút tiền hoặc các hoạt động khác.

Một Gas Token tương tự như 1inch CHI Token hoạt động như sau: duy trì một offset, luôn triển khai CREATE2 hoặc SELFDESTRUCT tại offset này. Sau cập nhật này, nếu hợp đồng tại offset hiện tại không được phá hủy đúng cách, các CREATE2 tiếp theo sẽ không thể triển khai hợp đồng thành công.

Đề xuất triển khai này không thể tấn công trực tiếp vào các hợp đồng, nhưng nó sẽ gây hỏng logic bình thường của các hợp đồng hiện tại phụ thuộc vào các hoạt động selfdestruct (các hợp đồng chỉ phụ thuộc vào selfdestruct để chuyển quỹ không bị ảnh hưởng, nhưng các hợp đồng yêu cầu các hoạt động sau đó để xóa các hợp đồng selfdestruct bị ảnh hưởng), gây ra các hợp đồng hoạt động một cách không mong muốn, và có thể dẫn đến các vấn đề như đình công hợp đồng, mất quỹ, v.v. (ví dụ, các hợp đồng mà ban đầu sử dụng create2 để triển khai các 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 thành công nữa). Trong tương lai, việc sửa đổi chức năng của một opcode có thể mang lại các vấn đề tập trung.

Ví dụ, có một hợp đồng két đang tồn tại để cập nhật:

  • Hợp đồng lưu trữ tạm thời, create2, được sử dụng để tạm thời dự trữ tiền cho ngăn két.
  • Tự hủy hợp đồng két, chuyển tiền vào hợp đồng tạm thời (chỉ chuyển tiền mà không đốt hợp đồng).
  • Tạo một hợp đồng két mới tại địa chỉ ban đầu bằng cách sử dụng create2 (thất bại vì hợp đồng két ban đầu chưa được đốt cháy).
  • Tự hủy hợp đồng tạm thời để trả lại tiền vào két (tiền bị mất, hợp đồng két chưa được tạo ra).

Đọ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, những thay đổi đối với lớp hợp đồng thông minh cốt lõi trong bản nâng cấp này mang lại rủi ro 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 tiềm ẩn mà chúng có thể mang lại cần được theo dõi 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 đọc thêm để hiểu những thay đổi.

Cancun Network Upgrade Specification

EIP-1153

EIP-4788

EIP-4844

EIP-5656

EIP-6780

EIP-7516

Hợp đồng Metapod

Hợp đồng GasToken2

Disclaimer:

  1. Bài viết này được sao chép từ [Aicoin]Chuyển tiếp Tiêu đề Gốc ‘Salus Insights: Điều cần thiết mà các nhà phát triển dự án cần xem trước khi nâng cấp Cancun. Bản quyền thuộc về tác giả gốc [‘*Odaily Planet hàng ngày]. Nếu có ý kiến ​​phản đối về việc tái in này, vui lòng liên hệ Gate Learnđội, và họ sẽ xử lý nhanh chóng.
  2. Tuyên bố từ chối 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 cấu thành bất kỳ lời khuyên đầu tư nào.
  3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được nêu ra, 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.
ابدأ التداول الآن
اشترك وتداول لتحصل على جوائز ذهبية بقيمة
100 دولار أمريكي
و
5500 دولارًا أمريكيًا
لتجربة الإدارة المالية الذهبية!