Hợp đồng thông minh là gì?

Ethereum có hai loại tài khoản phổ biến: Tài khoản sở hữu bên ngoài (EOA) và Tài khoản hợp đồng thông minh (SCA).

EOA rất giống với các tài khoản tài chính điện tử mà chúng ta thường sử dụng để lưu trữ tiền và tương tác với các ứng dụng. Ví dụ, người dùng gửi tiền fiat thông qua PayPal và tương tác với các trang web, cửa hàng và ứng dụng khác nhau để thanh toán. Các thợ đào DeFi thường lưu trữ tiền điện tử trong EOA của họ, tương tác với các ứng dụng phi tập trung DeFi và gửi tiền vào các ứng dụng phi tập trung để kiếm lợi nhuận. Tuy nhiên, EOA có một tính năng mà các tài khoản tài chính điện tử không có: người dùng phải có quyền kiểm soát EOA được xác minh thông qua quyền sở hữu khóa riêng - không có khóa của bạn, không có tiền của bạn.

SCA cũng là một loại tài khoản về cơ bản được liên kết với một đoạn mã byte có thể thực thi (còn được gọi là hợp đồng thông minh). Hợp đồng thông minh mô tả các logic kinh doanh khác nhau và đóng vai trò là phần backend cho các ứng dụng phi tập trung. Tuy nhiên, mặc dù có nhiều hạn chế hơn so với các ngôn ngữ phát triển Turing hoàn chỉnh truyền thống, các hợp đồng thông minh gần như Turing hoàn chỉnh vẫn dễ bị tấn công nhiều lần, gây ra vô số thiệt hại cho ngành công nghiệp blockchain.

Các cuộc tấn công hợp đồng thông minh phổ biến

1. Tấn công tái nhập

Cuộc tấn công phổ biến và tai tiếng nhất là tấn công tái nhập, đã dẫn đến việc phân tách Ethereum và tạo ra Ethereum Classic. Năm 2016, tin tặc đã thực hiện một cuộc tấn công tái nhập vào hợp đồng DAO, đánh cắp 3.600.000 ETH trị giá hơn 150 triệu đô la tại thời điểm đó. Cuộc tấn công này, diễn ra trong giai đoạn đầu của Ethereum, đã tàn phá hệ sinh thái và làm mất niềm tin của nhà đầu tư, cuối cùng dẫn đến việc phân tách.

Logic cụ thể

Dưới đây là một ví dụ để giúp bạn hiểu rõ hơn về nguyên tắc của cuộc tấn công tái nhập. Ngân hàng B trước đây đã cho Ngân hàng A vay một số tiền. Một ngày nọ, Ngân hàng B bắt đầu chuyển tiền cho Ngân hàng A, yêu cầu chuyển toàn bộ số tiền trở lại cho Ngân hàng B. Quá trình bình thường diễn ra như sau:

Bước 1: Ngân hàng B yêu cầu rút tiền

Bước 2: Ngân hàng A chuyển tiền cho Ngân hàng B

Bước 3: Ngân hàng A xác nhận việc chuyển tiền thành công cho Ngân hàng B

Bước 4: Ngân hàng A cập nhật số dư tài khoản của Ngân hàng B.

Tuy nhiên, nếu Ngân hàng B tạo ra một lỗ hổng sau Bước 2 và tiếp tục yêu cầu toàn bộ số tiền từ Ngân hàng A mà không có xác nhận ở Bước 3, thì số dư tài khoản của Ngân hàng A tại Ngân hàng B sẽ không thay đổi. Cuộc gọi đệ quy này sẽ làm cạn kiệt toàn bộ tài sản của Ngân hàng A.

Các Hợp đồng Thông minh Liên quan

Hợp đồng của Ngân hàng A bao gồm hai chức năng:

deposit(): Một chức năng gửi tiền để nạp tiền vào Ngân hàng A và cập nhật số dư của người dùng;
withdraw(): Một chức năng rút tiền cho phép người dùng rút toàn bộ số tiền của họ từ Ngân hàng A.

Hợp đồng tấn công của Ngân hàng B chủ yếu liên quan đến một vòng lặp kích hoạt hàm callback receive(), hàm này lại gọi hàm withdraw() của hợp đồng Ngân hàng để rút cạn tài sản của Ngân hàng A thông qua một chuỗi gồm 1 lần gửi tiền, 1 lần rút tiền và các cuộc gọi hàm callback receive(), và cuối cùng cập nhật số dư của B trong A. Nó bao gồm hai chức năng:receive(): Một hàm callback được kích hoạt khi nhận ETH, hàm này đệ quy gọi hàm withdraw() của hợp đồng Ngân hàng để thực hiện rút tiền.
attack(): Đầu tiên nó gọi hàm deposit() của hợp đồng Ngân hàng để làm mới số dư và sau đó gọi hàm withdraw() để bắt đầu lần rút tiền đầu tiên, và kích hoạt hàm callback receive() để đệ quy gọi withdraw() nhằm rút cạn tài sản của hợp đồng Ngân hàng.

Giải pháp

Triển khai khóa chống tái nhập

Khóa chống tái nhập là một bổ sung được sử dụng để ngăn chặn tái nhập, đảm bảo rằng một lệnh gọi phải hoàn thành việc thực thi trước khi nó có thể được gọi lại. Ví dụ, vì cuộc tấn công của Ngân hàng B yêu cầu gọi hàm withdraw() của hợp đồng Bank nhiều lần, nó sẽ thất bại khi triển khai khóa chống tái nhập.

Cách Sử Dụng

2. Sử dụng sai tx.origin

Chức năng chính của tx.origin trong một hợp đồng thông minh là truy xuất tài khoản ban đầu đã khởi tạo giao dịch. Ở đây, chúng ta sẽ thảo luận về hai biến phổ biến trong các hợp đồng thông minh: msg.sender và tx.origin . msg.sender truy xuất tài khoản trực tiếp gọi hợp đồng thông minh, trong khi trong thế giới blockchain, do sự lồng ghép và gọi lẫn nhau của các hợp đồng thông minh khác nhau (như DeFi Lego), tx.origin được cần đến để lấy tài khoản gốc đã khởi tạo giao dịch. Một lỗ hổng phát sinh khi các nhà phát triển dApp chỉ xác minh bảo mật của tx.origin trong mã, bỏ qua việc xác minh bảo mật của những kẻ tấn công triển khai các hợp đồng trung gian để vượt qua tx.origin và phát động các cuộc tấn công.

Logic cụ thể

Đây là một ví dụ để bạn đi sâu vào kịch bản tấn công phổ biến. Bill có một ví thông minh xác minh xem Bill có phải là người khởi tạo chuyển khoản hay không. Một lần, Bill đã tạo ra một NFT trên một trang web lừa đảo. Điều đó cho phép trang web lấy được danh tính của Bill và khởi tạo chuyển khoản từ ví thông minh của anh ấy bằng cách sử dụng danh tính của anh ấy, dẫn đến mất tài sản. Trong trường hợp bình thường, người dùng ít có khả năng mắc phải cạm bẫy này, nhưng khi tương tác với các dApp bằng ví, họ thường quên kiểm tra các lời nhắc tương tác. Ví dụ, nếu cả hai đều liên quan đến hàm Mint(), người dùng không cẩn thận có thể dễ dàng rơi vào bẫy lừa đảo. Logic kinh doanh trong trang web lừa đảo chứa đầy cạm bẫy, vì vậy điều quan trọng là phải kiểm tra các lời nhắc tương tác để phát hiện lỗi trong quá trình tương tác thông thường.

Hợp đồng Ví thông minh

Hợp đồng ví thông minh bao gồm một chức năng:

transfer(): Một chức năng rút tiền chỉ có thể được khởi tạo bởi chủ sở hữu ví, trong trường hợp này là Bill.

Hợp đồng Tấn công lừa đảo

Trong một hợp đồng tấn công lừa đảo, hàm Mint() dụ dỗ người dùng chuyển tiền đến địa chỉ của hacker. Nó bao gồm một chức năng:

Mint(): Khi được gọi, chức năng lừa đảo sẽ thực thi nội bộ transfer() của hợp đồng Wallet. Vì người khởi tạo ban đầu là chính người dùng (trong ví dụ này là Bill), nên việc xác minh require(tx.origin == owner, "Not owner") ; sẽ không gặp vấn đề. Tuy nhiên, địa chỉ đích cho việc chuyển tiền đã bị can thiệp thành địa chỉ của hacker, dẫn đến việc đánh cắp tiền.

Giải pháp

1. Sử dụng msg.sender thay vì tx.origin

Bất kể có bao nhiêu cuộc gọi hợp đồng liên quan (Hợp đồng A → Hợp đồng B →…→ hợp đồng mục tiêu), chỉ xác minh msg.sender, tức là người gọi trực tiếp, để tránh các cuộc tấn công gây ra bởi các hợp đồng trung gian độc hại.

2. Xác minh tx.origin == msg.sender

Phương pháp này có thể giữ các hợp đồng độc hại tránh xa, nhưng các nhà phát triển cần xem xét thực tế kinh doanh của riêng họ vì nó cô lập hiệu quả tất cả các cuộc gọi hợp đồng bên ngoài khác.

3. Tấn công Trình tạo số ngẫu nhiên (RNG)

Điều này quay trở lại xu hướng ứng dụng phi tập trung (dApp) về đánh bạc hoặc cá cược khoảng năm 2018 và 2019. Thông thường, các nhà phát triển sử dụng một số hạt giống nhất định trong hợp đồng thông minh để tạo ra các số ngẫu nhiên nhằm chọn người chiến thắng trong các đợt quay thưởng. Các hạt giống phổ biến bao gồm block.number, block.timestamp, blockhash và keccak256. Tuy nhiên, thợ đào có thể kiểm soát hoàn toàn các hạt giống này, vì vậy trong một số trường hợp, các thợ đào độc hại có thể thao túng các biến để thu lợi.

Hợp đồng Xúc xắc Thông thường

Hợp đồng Xúc xắc bao gồm một chức năng:

Bet(): Một chức năng đặt cược trong đó người dùng nhập số đặt cược và trả một khoản ETH. Một số ngẫu nhiên được tạo ra với nhiều hạt giống, và nếu số đặt cược khớp với số ngẫu nhiên, người dùng sẽ thắng toàn bộ tiền thưởng.

Hợp đồng Tấn công của Thợ đào

Thợ đào có thể chiến thắng miễn là họ tính toán trước số ngẫu nhiên chiến thắng và thực hiện nó trong cùng một khối. Điều này bao gồm một chức năng:

attack(): Một chức năng tấn công đặt cược, trong đó thợ đào tính toán trước số ngẫu nhiên chiến thắng. Vì nó được thực hiện trong cùng một khối, blockhash(block.number - 1) và block.timestamp trong cùng một khối là giống nhau. Sau đó, thợ đào gọi Bet() của hợp đồng Xúc xắc để hoàn thành cuộc tấn công.

Giải pháp

Sử dụng số ngẫu nhiên ngoài chuỗi được cung cấp bởi các dự án oracle

Thông qua các dịch vụ được cung cấp bởi các dự án oracle như Chainlink, các số ngẫu nhiên trên chuỗi được đưa vào các hợp đồng trên chuỗi để đảm bảo tính ngẫu nhiên và bảo mật. Tuy nhiên, các dự án oracle cũng mang theo những rủi ro tập trung hóa, do đó đòi hỏi các dịch vụ oracle trưởng thành hơn.

4. Tấn công Phát lại

Tấn công phát lại liên quan đến việc khởi động lại một giao dịch bằng cách sử dụng chữ ký đã sử dụng trước đó để đánh cắp tiền. Một trong những cuộc tấn công phát lại nổi tiếng nhất trong những năm gần đây là vụ đánh cắp 20 triệu token $OP từ nhà tạo lập thị trường Wintermute trên Optimism, đây là một cuộc tấn công phát lại xuyên chuỗi. Vì tài khoản ví đa chữ ký của Wintermute chỉ được triển khai tạm thời trên mạng chính Ethereum, kẻ tấn công đã sử dụng chữ ký của giao dịch triển khai địa chỉ đa chữ ký của Wintermute trên Ethereum để thực thi lại cùng một giao dịch trên chuỗi Optimism, từ đó giành quyền kiểm soát tài khoản ví đa chữ ký trên Optimism. Một tài khoản ví đa chữ ký về cơ bản là một tài khoản hợp đồng thông minh, điều này cũng cho thấy sự khác biệt đáng kể giữa SCA và EOA. Đối với EOA, một người dùng bình thường chỉ cần một khóa riêng để kiểm soát tất cả các địa chỉ trên Ethereum và các chuỗi tương thích với EVM (các chuỗi địa chỉ hoàn toàn giống nhau), trong khi SCA chỉ có hiệu lực trên một chuỗi sau khi được triển khai.

Logic Cụ thể

Ở đây, chúng tôi cung cấp một ví dụ về cuộc tấn công phát lại điển hình (tấn công phát lại trên cùng một chuỗi). Bill có một ví thông minh yêu cầu anh ấy nhập chữ ký điện tử của mình trước khi mỗi giao dịch có thể được thực hiện. Bây giờ kẻ tấn công Lucy đã đánh cắp chữ ký điện tử của Bill, cô ấy có thể khởi tạo vô số giao dịch để rút cạn ví thông minh của Bill.

Ví dụ

Một hợp đồng có lỗ hổng bao gồm ba chức năng:

checkSig(): Hàm xác minh ECDSA, đảm bảo rằng kết quả xác minh là người ký ban đầu đã được thiết lập.
getMsgHash(): Hàm tạo hash, kết hợp to và amount để tạo thành hash.
transfer(): Hàm chuyển tiền, cho phép người dùng rút tiền từ nhóm thanh khoản. Do thiếu hạn chế đối với chữ ký, cùng một chữ ký có thể được tái sử dụng, cho phép tin tặc liên tục đánh cắp tiền.

Giải pháp

Bao gồm nonce trong kết hợp chữ ký để ngăn chặn tấn công tái phát. Nguyên tắc của tham số này như sau:

nonce: Nó mô tả biến số của số lượng giao dịch của một EOA trong mạng blockchain. Nó có thứ tự và tính duy nhất. Với mỗi giao dịch bổ sung, giá trị nonce sẽ tăng lên 1. Mạng blockchain sẽ kiểm tra xem nonce của giao dịch có nhất quán với nonce hiện tại của tài khoản hay không. Do đó, một hacker sẽ thất bại nếu anh ta sử dụng một chữ ký đã được sử dụng vì giá trị nonce trong kết hợp chữ ký nhỏ hơn giá trị nonce hiện tại của EOA.

5. Tấn công Từ chối Dịch vụ (DoS)

Tấn công Từ chối Dịch vụ (DoS) không phải là điều gì mới trong thế giới Web2 truyền thống. Nó đề cập đến bất kỳ sự can thiệp nào với một máy chủ, chẳng hạn như gửi một lượng lớn thông tin rác hoặc gây rối, cản trở hoặc phá hủy hoàn toàn khả năng sẵn có. Tương tự, các hợp đồng thông minh cũng bị ảnh hưởng bởi những cuộc tấn công như vậy, về cơ bản nhằm làm cho hợp đồng thông minh hoạt động sai lệch.

Logic cụ thể

Hãy xem một ví dụ. Bên dự án A đang tiến hành chào bán công khai token của giao thức, trong đó tất cả người dùng có thể đóng góp tiền vào nhóm thanh khoản (Hợp đồng thông minh) để mua hạn ngạch theo nguyên tắc ai đến trước được phục vụ trước, và số tiền thừa sẽ được hoàn trả cho những người tham gia. Hacker Alice khai thác hợp đồng tấn công để tham gia vào đợt chào bán công khai. Khi nhóm thanh khoản cố gắng hoàn trả tiền cho hợp đồng tấn công của Alice, một cuộc tấn công DoS sẽ được kích hoạt, ngăn chặn hành động hoàn trả không bao giờ được thực hiện. Kết quả là, một lượng lớn tiền bị khóa trong hợp đồng thông minh.

Ví dụ về hợp đồng phát hành công khai

Ví dụ

Hợp đồng phát hành công khai bao gồm hai chức năng:

deposit(): chức năng gửi tiền, ghi lại địa chỉ của người gửi và số tiền đóng góp.
refund(): chức năng hoàn tiền, mà đội ngũ dự án sử dụng để trả lại tiền cho các nhà đầu tư.

Hợp đồng tấn công DoS

Hợp đồng tấn công DoS bao gồm một chức năng:

attack(): Mặc dù là một chức năng tấn công, nó không có bất kỳ vấn đề gì. Vấn đề chính nằm ở hàm gọi lại thanh toán receive() được tích hợp sẵn trong hợp đồng Hacker, bao gồm một phán đoán về các ngoại lệ. Bất kỳ hợp đồng bên ngoài nào chuyển tiền đến hợp đồng Hacker sẽ kích hoạt một ngoại lệ thông qua revert(), từ đó ngăn chặn hoạt động hoàn thành.

Giải pháp

1. Tránh chức năng quan trọng bị kẹt khi gọi các hợp đồng bên ngoài

Loại bỏ require(success, "Refund Fail!"); khỏi hàm refund() của hợp đồng PublicSale ở trên, đảm bảo rằng hoạt động hoàn tiền có thể tiếp tục ngay cả khi việc hoàn tiền cho một địa chỉ đơn lẻ thất bại.

2. Tách rời

Trong hàm refund() của hợp đồng PublicSale ở trên, cho phép người dùng tự yêu cầu hoàn tiền thay vì phân phối hoàn tiền, từ đó giảm thiểu các tương tác không cần thiết với các hợp đồng bên ngoài.

6. Tấn công permit

Trong một cuộc tấn công bằng cách cấp phép, Tài khoản A cung cấp chữ ký cho một bên được chỉ định trước, và sau đó Tài khoản B, khi có được chữ ký, có thể thực hiện các giao dịch chuyển token được ủy quyền để đánh cắp một số lượng token nhất định. Ở đây, chúng ta chủ yếu thảo luận về hai chức năng phổ biến để ủy quyền token trong Hợp đồng Thông minh: approve() và permit().

Trong hợp đồng ERC20 thông thường, Tài khoản A có thể gọi approve() để ủy quyền một số lượng token nhất định cho Tài khoản B, cho phép tài khoản sau chuyển những token đó từ tài khoản trước. Ngoài ra, permit() đã được giới thiệu vào các hợp đồng ERC20 trong EIP-2612, và Uniswap đã phát hành một tiêu chuẩn ủy quyền token mới, Permit2, vào tháng 11 năm 2022.

Logic cụ thể

Dưới đây là một ví dụ. Một ngày nọ, Bill đang duyệt một trang web tin tức blockchain khi đột nhiên xuất hiện một cửa sổ pop-up yêu cầu chữ ký Metamask. Vì nhiều trang web hoặc ứng dụng blockchain sử dụng chữ ký để xác minh đăng nhập của người dùng, Bill không suy nghĩ nhiều và hoàn thành chữ ký trực tiếp. Năm phút sau, tài sản Metamask của anh ấy bị rút cạn. Bill sau đó phát hiện trong trình khám phá blockchain rằng một địa chỉ không xác định đã khởi tạo một giao dịch permit(), tiếp theo là một giao dịch transferFrom() làm rỗng ví của anh ấy.

Ví dụ

Hai chức năng như sau:

approve(): Một chức năng ủy quyền tiêu chuẩn trong đó Tài khoản A ủy quyền một số lượng tiền nhất định cho Tài khoản B.
permit(): Một chức năng ủy quyền bằng chữ ký trong đó Tài khoản B gửi và hoàn thành xác minh chữ ký để nhận được số tiền được ủy quyền từ Tài khoản A. Các tham số bao gồm chủ sở hữu cấp ủy quyền, người được ủy quyền, số tiền được ủy quyền, thời hạn chữ ký, và dữ liệu chữ ký v, r, và s của chủ sở hữu.

Giải pháp

1. Chú ý đến mọi chữ ký trong các tương tác trên chuỗi

Mặc dù một số ví có biện pháp giải mã và hiển thị thông tin chữ ký ủy quyền approve(), họ hầu như không cảnh báo về việc lừa đảo chữ ký permit(), làm tăng nguy cơ tấn công. Do đó, việc kiểm tra kỹ lưỡng mọi chữ ký không xác định để đảm bảo liệu nó có nhắm vào hàm permit() hay không được khuyến nghị mạnh mẽ.

2. Tách riêng ví dùng cho tương tác thường xuyên khỏi ví lưu trữ tài sản

Điều này cực kỳ quan trọng đối với người dùng tiền điện tử, đặc biệt là những người săn airdrop, vì họ tương tác với vô số dApp hoặc trang web mỗi ngày và dễ rơi vào bẫy. Việc chỉ lưu trữ một lượng nhỏ tiền trong ví dùng cho tương tác thường xuyên có thể giữ tổn thất trong phạm vi có thể kiểm soát được.

7. Tấn công Honeypot

Trong ngành công nghiệp blockchain, tấn công honeypot đề cập đến một loại hợp đồng token độc hại được triển khai bởi các đội ngũ dự án. Hợp đồng chỉ cấp quyền bán cho đội ngũ dự án, trong khi người dùng thông thường chỉ có thể mua thay vì bán, do đó chịu tổn thất.

Logic cụ thể

Đây là một ví dụ. Trong một thông báo trên Telegram, Bên dự án A thông báo cho người dùng rằng token đã được triển khai trên mạng chính và có sẵn để giao dịch. Do token chỉ có thể được mua và không thể bán, giá ban đầu tiếp tục tăng vọt, và những người dùng sợ bỏ lỡ cơ hội tiếp tục mua vào. Sau một thời gian khi người dùng nhận ra không thể bán, đội ngũ dự án nắm bắt cơ hội và bán đổ bán tháo token, khiến giá lao dốc.

Ví dụ

Chức năng cốt lõi:

_beforeTokenTransfer(): Một hàm nội bộ được gọi trong quá trình chuyển token, chỉ có thể thành công khi được gọi bởi chủ sở hữu; các cuộc gọi từ tài khoản khác sẽ thất bại.

Giải pháp

Sử dụng công cụ quét bảo mật

a. Token Sniffer cho các token Ethereum

b. Ave Check cho các token trên các chuỗi khác

c. Các trang web thị trường với các công cụ phát hiện tích hợp như Dextools

Tránh giao dịch các token có điểm số thấp.

8. Tấn công Front-Running

Front-running ban đầu xuất hiện trong các thị trường tài chính truyền thống, nơi sự bất đối xứng thông tin cho phép các trung gian tài chính thu lợi bằng cách thực hiện các hành động nhanh chóng dựa trên thông tin ngành cụ thể. Trong ngành blockchain, front-running chủ yếu bắt nguồn từ front-running trên chuỗi, liên quan đến việc thao túng thợ đào để ưu tiên đóng gói giao dịch của chính họ vào chuỗi nhằm thu lợi nhuận.

Trong lĩnh vực blockchain, thợ đào có thể kiếm lợi bằng cách thao túng các giao dịch họ đóng gói vào các khối, ví dụ như loại trừ một số giao dịch nhất định và sắp xếp lại thứ tự giao dịch. Lợi nhuận như vậy có thể được đo lường bằng Giá trị Có thể Trích xuất của Thợ đào (MEV). Trước khi giao dịch của người dùng được thêm vào mạng chính Ethereum, phần lớn các giao dịch được tập hợp trong mempool. Thợ đào tìm kiếm các giao dịch có giá gas cao hơn trong mempool này và ưu tiên đóng gói chúng để tối đa hóa lợi nhuận của họ. Nói chung, các giao dịch có giá gas cao hơn dễ được thợ đào đóng gói hơn. Trong khi đó, một số bot MEV cũng tìm kiếm các giao dịch có khả năng sinh lời trong mempool.

Logic cụ thể

Dưới đây là một ví dụ. Bill phát hiện ra một token mới nóng hổi với biến động giá đáng kể. Để đảm bảo thành công của các giao dịch token trên Uniswap, Bill đặt phạm vi trượt giá cực kỳ rộng. Không may thay, bot MEV của Alice phát hiện giao dịch này trong mempool và nhanh chóng tăng phí gas, khởi tạo giao dịch mua trước giao dịch của Bill và chèn giao dịch bán sau giao dịch của Bill trong cùng một khối. Sau khi khối được xác nhận, điều này gây ra tổn thất trượt giá đáng kể cho Bill, trong khi Alice thu lợi từ một hoạt động chênh lệch giá mua thấp bán cao.

Ví dụ

Chức năng như sau:

solve(): Một hàm đoán trong đó bất kỳ ai cũng có thể gửi câu trả lời, và nếu câu trả lời gửi đi khớp với câu trả lời mục tiêu, người gửi có thể nhận được 10 ether.

Quy trình: Bill tìm ra câu trả lời đúng.
Alice theo dõi mempool, chờ đợi ai đó gửi câu trả lời đúng.
Bill gọi hàm solve() để gửi câu trả lời và đặt giá gas là 100 Gwei.
Alice thấy giao dịch được gửi bởi Bill và phát hiện ra câu trả lời. Cô ấy đặt giá gas cao hơn Bill là 200 Gwei và gọi hàm solve().
Giao dịch của Alice được đóng gói bởi thợ đào trước giao dịch của Bill.
Alice giành được phần thưởng 10 ether.

Giải pháp

Ba chức năng chính như sau:

commitSolution(): Một hàm để gửi kết quả, đặt câu trả lời solutionHash được gửi bởi người dùng, thời gian gửi commitTime, và trạng thái revealed vào cấu trúc Commit.
getMySolution(): Một hàm để lấy kết quả, cho phép người dùng xem câu trả lời đã gửi và thông tin liên quan, bao gồm câu trả lời solutionHash được gửi bởi người dùng, thời gian gửi commitTime, và trạng thái revealed.
revealSolution(): Một hàm để yêu cầu phần thưởng cho việc đoán đúng câu đố, cho phép người dùng yêu cầu phần thưởng sau khi cung cấp câu trả lời và mật khẩu họ đã đặt.

Quy trình:

Bill tìm ra câu trả lời đúng.
Bill gọi hàm commitSolution() để gửi câu trả lời đúng.
Trong khối tiếp theo, Bill gọi hàm revealSolution(), cung cấp câu trả lời và mật khẩu mà anh ấy đã đặt để nhận phần thưởng.

Trong hàm commitSolution(), Bill gửi một chuỗi được mã hóa, chỉ giữ dữ liệu văn bản thuần túy được gửi cho riêng mình. Trong bước này, thời gian khối gửi commitTime cũng được ghi lại. Tiếp theo, trong hàm revealSolution(), thời gian khối được kiểm tra để ngăn chặn việc chạy đua trong cùng một khối. Vì việc gọi revealSolution() yêu cầu gửi câu trả lời dưới dạng văn bản thuần túy, bước này nhằm ngăn chặn người khác bỏ qua commitSolution() và gọi trực tiếp revealSolution(). Sau khi xác minh thành công, phần thưởng sẽ được phân phối nếu câu trả lời được kiểm tra là chính xác.

Kết luận

Hợp đồng thông minh đóng vai trò quan trọng trong công nghệ blockchain và mang lại nhiều lợi ích. Đầu tiên, chúng cho phép thực thi tự động, phi tập trung, đảm bảo an toàn và đáng tin cậy cho giao dịch mà không cần bên thứ ba. Thứ hai, hợp đồng thông minh giảm các bước trung gian và chi phí, nâng cao hiệu quả giao dịch.

Mặc dù có rất nhiều lợi ích, hợp đồng thông minh cũng đối mặt với nguy cơ bị tấn công gây thiệt hại tài chính cho người dùng. Do đó, một số thói quen là cần thiết đối với người dùng trên chuỗi. Đầu tiên, người dùng nên luôn cẩn thận lựa chọn dApps để tương tác và xem xét kỹ lưỡng mã hợp đồng và các quy tắc liên quan. Ngoài ra, họ nên thường xuyên cập nhật và sử dụng ví an toàn và các công cụ tương tác hợp đồng để giảm thiểu rủi ro bị tấn công bởi hacker. Hơn nữa, nên lưu trữ tiền của họ ở nhiều địa chỉ khác nhau để giảm thiểu tổn thất tiềm ẩn từ các cuộc tấn công hợp đồng.

Đối với các tổ chức trong ngành, việc đảm bảo an ninh và ổn định của các hợp đồng thông minh cũng quan trọng không kém. Ưu tiên hàng đầu nên là tăng cường kiểm toán các hợp đồng thông minh để xác định và khắc phục các lỗ hổng và rủi ro bảo mật tiềm ẩn. Thứ hai, các tổ chức trong ngành nên cập nhật thông tin về những phát triển mới nhất của blockchain liên quan đến các cuộc tấn công hợp đồng và thực hiện các biện pháp bảo mật phù hợp. Cuối cùng nhưng không kém phần quan trọng, họ cũng nên tăng cường giáo dục người dùng và nâng cao nhận thức về bảo mật trong việc sử dụng đúng cách các hợp đồng thông minh.

Tóm lại, với nỗ lực phối hợp của cả người dùng và các tổ chức trong ngành, các rủi ro bảo mật do hợp đồng thông minh gây ra có thể được giảm thiểu đáng kể. Người dùng nên luôn cẩn thận lựa chọn hợp đồng và bảo vệ tài sản cá nhân, trong khi các tổ chức trong ngành nên tăng cường kiểm toán hợp đồng, cập nhật những tiến bộ công nghệ, và nâng cao giáo dục người dùng cũng như nhận thức về bảo mật. Cùng nhau, chúng ta sẽ thúc đẩy sự phát triển an toàn và đáng tin cậy của các hợp đồng thông minh.

Tài liệu tham khảo:

Solidity by Example：https://solidity-by-example.org/

Blockchain Know-how của SlowMist：https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzU4ODQ3NTM2OA==&action=getalbum&album_id=1378673890158936067&scene=173&from_msgid=2247498135&from_itemidx=1&count=3&nolastread=1#wechat_redirect

Chainlink - Top 10 Phương pháp Thực hành Tốt nhất về Bảo mật DeFi：https://blog.chain.link/defi-security-best-practices/#post-title

WTF - Solidity 104 Bảo mật Hợp đồng：https://www.wtf.academy/solidity-104/

Lỗ hổng trong Hợp đồng Thông minh DeFi trong 4 Danh mục với 38 Kịch bản：https://www.weiyangx.com/381670.html

OpenZeppelin：https://github.com/OpenZeppelin/