Hợp đồng thông minh là gì?
Có hai loại tài khoản phổ biến trên Ethereum: Tài khoản thuộc 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 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 nhiều trang web, cửa hàng và ứng dụng khác nhau để thanh toán. Người dùng DeFi thường lưu trữ tiền điện tử trong EOA của họ, tương tác với các dApp DeFi và gửi tiền vào dApp để kiếm lợi nhuận. Tuy nhiên, EOA có một tính năng mà tài khoản tài chính điện tử không có: người dùng kiểm soát EOA thông qua sở hữu khóa riêng tư. Hay nói cách khác, không có khóa tương đương với không phải 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 thực thi (còn được gọi là hợp đồng thông minh). Hợp đồng thông minh mô tả logic kinh doanh khác nhau và đóng vai trò là backend cho dApp. 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 hoàn chỉnh Turing truyền thống, các hợp đồng thông minh hoàn chỉnh gần giống Turing vẫn dễ bị tấn công, gây ra vô số đòn giáng cho ngành công nghiệp blockchain.
Các kiểu tấn công hợp đồng thông minh phổ biến
1. Tấn công reentrancy
Kiểu tấn công phổ biến và khét tiếng nhất là tấn công reentrancy, nguyên nhân gây ra fork Ethereum dẫn đến tạo ra Ethereum Classic. Vào năm 2016, hacker đã thực hiện một cuộc tấn công vào hợp đồng DAO, đánh cắp 3.600.000 ETH trị giá hơn 150 triệu đô la vào thời điểm đó. Cuộc tấn công này xảy ra trong giai đoạn đầu của Ethereum và tàn phá hệ sinh thái, làm tan vỡ niềm tin của nhà đầu tư, cuối cùng dẫn đến fork.
Logic cụ thể
Dưới đây là ví dụ giúp bạn hiểu rõ hơn về nguyên tắc của cuộc tấn công reentrancy. Trước đó, Ngân hàng B đã cho Ngân hàng A vay một số tiền. Một ngày nọ, Ngân hàng B tiến hành chuyển khoản cho Ngân hàng A, làm phát sinh yêu cầu chuyển toàn bộ số tiền trở lại Ngân hàng B. Cách làm thông thường 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 chuyển khoản thành công sang 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 kẽ hở 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. Lệnh gọi đệ quy này sẽ làm trống tất cả tài sản của Ngân hàng A.
Hợp đồng thông minh liên quan
Hợp đồng của Ngân hàng A bao gồm hai hàm:
– deposit(): Hàm gửi tiền vào Ngân hàng A và cập nhật số dư của người dùng;
– withdraw(): 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 vòng lặp kích hoạt hàm callback receive(), sau đó gọi hàm withdraw() của hợp đồng để tiêu hao tài sản của Ngân hàng A thông qua chuỗi 1 lần gửi, 1 lần rút, hàm callback receive() và cuối cùng cập nhật số dư của B trong A. Bao gồm hai hàm:
– receive(): Hàm callback được kích hoạt khi nhận được ETH, hàm này gọi đệ quy 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ư, sau đó gọi hàm withdraw() để bắt đầu lần rút tiền đầu tiên và kích hoạt callback receive() để gọi đệ quy withdraw() và rút tài sản theo hợp đồng của Ngân hàng.
Giải pháp
Thực hiện khóa reentrancy
Khóa reentrancy là một công cụ sửa đổi được sử dụng để ngăn chặn reentrancy, đảm bảo lệnh gọi phải hoàn thành việc thực hiện trước khi có thể gọi lại. Ví dụ: do 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 Ngân hàng nhiều lần nên không thể làm vậy với khóa reentrancy.
Cách sử dụng
2. Lạm dụng tx.origin
Chức năng chính của tx.origin trong hợp đồng thông minh là truy xuất tài khoản ban đầu đã thực hiện giao dịch. Ở đây, chúng ta sẽ thảo luận về hai biến thông dụng trong hợp đồng thông minh: msg.sender và tx.origin.
msg.sender truy xuất tài khoản gọi trực tiếp hợp đồng thông minh, trong khi trong thế giới blockchain, do các lệnh gọi lồng vào nhau và tương hỗ của các hợp đồng thông minh khác nhau (chẳng hạn như DeFi Lego), cần có tx.origin để lấy tài khoản ban đầu đã bắt đầu giao dịch. Lỗ hổng phát sinh khi các nhà phát triển dApp chỉ xác minh tính bảo mật của tx.origin trong code, bỏ qua việc xác minh bảo mật của những kẻ tấn công triển khai hợp đồng trung gian để tránh tx.origin và khởi động các cuộc tấn công.
Logic cụ thể
Ví dụ, Bill có một ví thông minh để xác minh xem Bill có phải là người khởi xướng chuyển khoản hay không. Một lần, Bill đã đúc được NFT trên một trang web phishing. Qua đó, trang web lấy được danh tính của Bill và bắt đầu chuyển tiền từ ví thông minh bằng danh tính của anh ấy, dẫn đến tổn thất tài sản. Trong trường hợp bình thường, người dùng ít có khả năng rơi vào bẫy này, nhưng khi tương tác với dApp bằng ví, họ thường quên kiểm tra 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 bất cẩn có thể dễ dàng rơi vào bẫy lừa đảo. Logic kinh doanh trong trang web phishing có nhiều bẫy, vì vậy điều quan trọng là phải kiểm tra lời nhắc tương tác để tìm 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 hàm:
– transfer(): Hàm rút tiền chỉ có thể được thực hiện bởi chủ sở hữu ví, trong trường hợp này là Bill.
Hợp đồng tấn công phishing
Trong hợp đồng tấn công phishing, Mint() xúi giục người dùng chuyển tiền đến địa chỉ của hacker. Bao gồm một hàm:
– Mint(): Sau khi được gọi, hàm phishing sẽ thực hiện nội bộ transfer() của hợp đồng ví. 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 có vấn đề gì. Tuy nhiên, địa chỉ đích để chuyển tiền đã bị giả mạo thành địa chỉ của hacker, dẫn đến hành vi trộm tiền.
Giải pháp
1. Sử dụng msg.sender thay vì tx.origin
Cho dù có bao nhiêu lệnh gọi hợp đồng liên quan (Hợp đồng A → Hợp đồng B →…→ hợp đồng đích), chỉ cần 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 do hợp đồng trung gian độc hại gây ra.
2. Xác minh tx.origin == msg.sender
Phương pháp này có thể loại bỏ các hợp đồng độc hại, nhưng các nhà phát triển cần xem xét thực tế làm việc của chính họ vì nó cách ly hiệu quả tất cả các lệnh gọi hợp đồng bên ngoài khác.
3. Tấn công tạo số ngẫu nhiên (RNG)
Kiểu tấn công này phổ biến trong xu hướng dApp cờ bạc hoặc cá cược vào 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 lần rút thăm. Các hạt giống phổ biến bao gồm block.number, block.timestamp, blockhash và keccak256. Tuy nhiên, thợ đào hoàn toàn có thể kiểm soát những hạt giống này, vì vậy trong một số trường hợp, những thợ đào độc hại thao túng các biến số để tư lợi.
Hợp đồng Dice thông thường
Hợp đồng Dice bao gồm một hàm:
– Bet(): Hàm cá cược trong đó người dùng nhập số cá cược và trả 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ẽ giành được toàn bộ pool giải thưởng.
Hợp đồng tấn công của thợ đào
Thợ đào có thể giành 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 block. Bao gồm một hàm:
– attack(): Hàm tấn công cá 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 thi trong cùng một block nên blockhash(block.number – 1) và block.timestamp trong cùng một block đều giống nhau. Sau đó, thợ đào gọi Bet() của hợp đồng Dice để hoàn thành cuộc tấn công.
Giải pháp
Sử dụng số ngẫu nhiên off-chain do các dự án oracle cung cấp
Thông qua các dịch vụ được các dự án oracle như Chainlink cung cấp, các số ngẫu nhiên off-chain được đưa vào các hợp đồng on-chain để đảm bảo tính ngẫu nhiên và bảo mật. Tuy nhiên, các dự án oracle cũng tiềm ẩn rủi ro về tập trung hóa, do đó cần có các dịch vụ oracle hoàn thiện hơn.
4. Tấn công lặp lại
Tấn công lặp lại là bắt đầu lại giao dịch bằng chữ ký đã sử dụng trước đó để đánh cắp tiền. Một trong những cuộc tấn công lặp lại nổi tiếng nhất vào những năm gần đây là hành vi trộm 20 triệu token OP từ nhà tạo lập thị trường Wintermute trên Optimism, là một cuộc tấn công lặp lại cross-chain. Do tài khoản ví đa chữ ký của Wintermute chỉ được triển khai tạm thời trên mainnet Ethereum nên hacker đã sử dụng chữ ký cho giao dịch mà Wintermute triển khai địa chỉ đa chữ ký trên Ethereum để thực hiện lại cùng một giao dịch trên chain Optimism, từ đó giành quyền kiểm soát tài khoản ví đa chữ ký trên Optimism. Tài khoản ví đa chữ ký về cơ bản là tài khoản hợp đồng thông minh, nên cũng thể hiện sự khác biệt đáng kể giữa SCA và EOA. Đối với EOA, người dùng bình thường chỉ cần một khóa riêng tư để kiểm soát tất cả các địa chỉ trên Ethereum và chain tương thích 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 chain sau khi được triển khai.
Logic cụ thể
Ở đây, chúng tôi cung cấp một ví dụ về kiểu tấn công lặp lại điển hình (tấn công lặp lại trên cùng chain). Bill có một ví thông minh yêu cầu anh phải nhập chữ ký điện tử trước khi thực hiện mỗi giao dịch. Hacker Lucy đã đánh cắp chữ ký điện tử của Bill và có thể thực hiện số lượng giao dịch không giới hạn để rút cạn ví thông minh của Bill.
Một hợp đồng có lỗ hổng bảo mật bao gồm ba hàm:
– checkSig(): Hàm xác minh ECDSA, đảm bảo kết quả xác minh là người ký được thiết lập ban đầu.
– getMsgHash(): Hàm tạo hash, kết hợp “to” và “amount” để tạo thành hash.
– transfer(): Hàm chuyển khoản, cho phép người dùng rút tiền từ pool thanh khoản. Do không có hạn chế về chữ ký, chữ ký tương tự có thể được sử dụng lại, cho phép hacker 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 các cuộc tấn công lặp lại. Nguyên lý của tham số này như sau:
– nonce: Mô tả biến số lượng giao dịch của EOA trong mạng blockchain. nonce được xếp theo trật tự và là duy nhất. Với mỗi giao dịch bổ sung, giá trị nonce sẽ tăng thêm 1. Mạng blockchain sẽ kiểm tra xem nonce của giao dịch có phù hợp với nonce hiện tại của tài khoản hay không. Do đó, hacker sẽ thất bại nếu sử dụng chữ ký đã sử dụng vì giá trị nonce trong 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 có gì mới trong thế giới Web2 truyền thống. Kiểu tấn công này được thực hiện bằng cách can thiệp vào máy chủ, chẳng hạn như gửi lượng lớn thông tin rác hoặc thông tin gây rối, cản trở hoặc phá hủy hoàn toàn tính khả dụng. Tương tự, các hợp đồng thông minh bị tấn công theo cách này về cơ bản nhằm mục đích làm cho hợp đồng thông minh gặp trục trặc.
Logic cụ thể
Ví dụ, dự án A đang tiến hành chào bán công khai token giao thức, trong đó tất cả người dùng có thể đóng góp tiền vào pool thanh khoản (Hợp đồng thông minh) để mua định mức trên cơ sở ai đến trước được phục vụ trước và số tiền vượt quá sẽ được trả lại cho người tham gia. Hacker Alice lợi dụng hợp đồng tấn công để tham gia IPO. Khi pool thanh khoản cố gắng trả lại tiền cho hợp đồng tấn công của Alice, cuộc tấn công DoS sẽ được kích hoạt, ngăn chặn hành động hoàn trả đượ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ụ
Hợp đồng chào bán ra công chúng bao gồm hai hàm:
– deposit(): Hàm gửi tiền, ghi lại địa chỉ của người gửi tiền và số tiền đã góp.
– return(): Hàm hoàn lại tiền, trong đó team dự án sẽ trả lại tiền cho nhà đầu tư.
Hợp đồng tấn công DoS
Hợp đồng tấn công DoS bao gồm một hàm:
– attack(): Mặc dù là một hàm tấn công nhưng nó không có vấn đề gì. Vấn đề chính nằm ở hàm callback thanh toán receive() được tích hợp trong hợp đồng hacker, bao gồm cả phán quyết về các trường hợp ngoại lệ. Bất kỳ hợp đồng bên ngoài nào chuyển tiền cho hợp đồng hacker sẽ kích hoạt một ngoại lệ thông qua revert(), do đó ngăn hoạt động hoàn tất.
Các giải pháp
Tránh để hàm quan trọng bị kẹt khi gọi các hợp đồng bên ngoài
Xóa yêu cầu require(success, “Refund Fail!”); từ hàm refund() nêu trên của hợp đồng PublicSale, đảm bảo hoạt động hoàn tiền có thể tiếp tục ngay cả khi việc hoàn tiền đến một địa chỉ không thành công.
Tách rời
Trong hàm refund() ở trên của hợp đồng PublicSale, cho phép người dùng yêu cầu hoàn tiền thay vì phân phối số tiền hoàn lại, 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 cho phép
Trong kiểu tấn công cho phép, Tài khoản A cung cấp trước chữ ký cho một bên được chỉ định và Tài khoản B sau khi có chữ ký có thể thực hiện chuyển token được ủy quyền để đánh cắp số lượng token nhất định. Ở đây, bài viết chủ yếu thảo luận về hai hàm phổ biến để ủy quyền token trong Hợp đồng thông minh: approve() và permit().
Trong hợp đồng ERC20, Tài khoản A có thể gọi approve() để ủy quyền số lượng token nhất định cho Tài khoản B, cho phép Tài khoản B chuyển các token đó từ Tài khoản A. Ngoài ra, permit() đã được đưa vào hợp đồng ERC20 trong EIP-2612 và Uniswap đã phát hành tiêu chuẩn ủy quyền token mới, Permit2, vào tháng 11/2022.
Logic cụ thể
Ví dụ, một ngày nọ, Bill đang duyệt trang web tin tức blockchain thì đột nhiên một cửa sổ bật lên có chữ ký Metamask xuất hiện. Vì nhiều trang web hoặc ứng dụng blockchain sử dụng chữ ký để xác minh thông tin đăng nhập của người dùng nên Bill không nghĩ nhiều về điều đó và trực tiếp hoàn thành chữ ký. 5 phút sau, tài sản Metamask của anh ta cạn kiệt. Sau đó, Bill phát hiện ra trong blockchain explorer rằng một địa chỉ không xác định đã bắt đầu giao dịch permit(), sau đó là giao dịch transferFrom() hút cạn ví của anh ấy.
Ví dụ
Hai hàm như sau:
– approve(): Hàm ủy quyền tiêu chuẩn trong đó Tài khoản A ủy quyền một số tiền nhất định cho Tài khoản B.
– permit(): Hàm ủy quyền chữ ký trong đó Tài khoản B gửi và hoàn tất xác minh chữ ký để nhận 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 chi tiêu đượ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.
Các giải pháp
1. Chú ý đến từng chữ ký trong tương tác on-chain
Bất chấp các biện pháp mà một số ví thực hiện để giải code và hiển thị thông tin chữ ký ủy quyền approve(), họ hầu như không đưa ra cảnh báo nào về phishing chữ ký permit(), làm tăng nguy cơ bị tấn công. Do đó, bạn nên kiểm tra nghiêm ngặt mọi chữ ký chưa biết để đảm bảo liệu nó có nhằm vào hàm permit() hay không.
2. Tách ví để tương tác thường xuyên với tài sản lưu trữ trong ví
Đ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 thợ săn airdrop, vì họ tương tác với vô số dApp hoặc trang web mỗi ngày và dễ bị mắc bẫy. Chỉ lưu trữ một lượng tiền nhỏ trong ví để tương tác thường xuyên có thể kiềm chế mức thiệt hại trong phạm vi chịu đượ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 các team dự án triển khai. Hợp đồng chỉ cấp cho team dự án quyền bán, trong khi người dùng thông thường chỉ có thể mua thay vì bán, do đó chịu lỗ.
Logic cụ thể
Ví dụ, trong một thông báo trên Telegram, dự án A thông báo cho người dùng rằng token đã được triển khai trên mainnet và có sẵn để giao dịch. Vì token chỉ có thể được mua và không thể bán nên giá ban đầu tiếp tục tăng cao và những người dùng sợ bỏ lỡ sẽ tiếp tục mua. Sau một thời gian khi người dùng nhận thấy không thể bán được, team dự án đã nắm bắt cơ hội và dump token khiến giá giảm mạnh.
Ví dụ
Hàm cốt lõi:
– _beforeTokenTransfer(): Một hàm nội bộ được gọi trong quá trình chuyển token, hàm này chỉ có thể thành công khi được chủ sở hữu gọi, lệnh gọi từ các tài khoản khác sẽ không thành công.
Giải pháp
Sử dụng các công cụ quét bảo mật
1. Token Sniffer dành cho các token Ethereum.
2. Ave Check cho token trên các chain khác.
3. Các trang web marketing với các công cụ phát hiện tích hợp như Dextools.
4. Tránh giao dịch token có điểm thấp.
8. Tấn công chạy trước
Hoạt động chạy trước ban đầu xuất hiện ở các thị trường tài chính truyền thống, nơi mà sự bất cân xứng thông tin cho phép các trung gian tài chính thu được lợi nhuận bằng cách thực hiện các hành động nhanh chóng dựa trên thông tin cụ thể của ngành. Trong ngành công nghiệp blockchain, hoạt động chạy trước chủ yếu bắt nguồn từ hoạt động chạy trước on-chain, bao gồm việc thao túng các thợ đào để ưu tiên đóng gói các giao dịch của chính mình vào chain nhằm thu được lợi nhuận.
Trong lĩnh vực blockchain, thợ đào có thể kiếm lợi nhuận bằng cách thao túng các giao dịch mà họ đóng gói thành các block, ví dụ: loại trừ một số giao dịch nhất định và sắp xếp lại các 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 mainnet Ethereum, phần lớn các giao dịch được tổng 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. Nói chung, các giao dịch có giá gas cao hơn sẽ được các thợ đào thực hiện dễ dàng hơn. Trong khi đó, một số bot MEV cũng lùng sục trong mempool để tìm các giao dịch mang lại lợi nhuận.
Logic cụ thể
Ví dụ, Bill phát hiện một “hot” token mới có biến động giá đáng kể. Để đảm bảo sự thành công của các giao dịch token trên Uniswap, Bill đặt ra phạm vi trượt giá đặc biệt rộng. Thật không may, bot MEV của Alice phát hiện giao dịch này trong mempool và nhanh chóng tăng phí gas, bắt đầu 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 block. Sau khi xác nhận block, đ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ừ hoạt động chênh lệch giá mua thấp và bán cao.
Ví dụ
Hàm này 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 được gửi khớp với câu trả lời đích thì người gửi có thể nhận được 10 ETH.
Quá trình:
1. Bill tìm được câu trả lời đúng.
2. Alice giám sát mempool, chờ ai đó gửi câu trả lời đúng.
3. Bill gọi solve() để gửi câu trả lời và đặt giá gas thành 100 Gwei.
4. Alice nhìn thấy giao dịch do Bill gửi và phát hiện câu trả lời. Cô đặt giá gas 200 Gwei cao hơn của Bill và gọi solve().
5. Giao dịch của Alice được thợ đào đóng gói trước giao dịch của Bill.
6. Alice giành được phần thưởng là 10 ETH.
Giải pháp
Ba hàm chính như sau:
– commitSolution(): Hàm gửi kết quả, đặt câu trả lời đã gửi của người dùng SolutionHash, thời gian gửi commitTime và trạng thái revealed (tiết lộ) vào cấu trúc Commit.
– getMySolution(): Hàm thu kết quả, cho phép người dùng xem các câu trả lời đã gửi và thông tin liên quan của họ, bao gồm cả câu trả lời đã gửi của người dùng solutionHash, thời gian gửi cam kết commitTime và trạng thái revealed.
– revealSolution(): Chức năng nhận phần thưởng khi đoán câu đố, cho phép người dùng nhận phần thưởng sau khi cung cấp câu trả lời và mật khẩu họ đặt.
Quá trình:
1. Bill tìm được câu trả lời đúng.
2. Bill gọi commitSolution() để gửi câu trả lời đúng.
3. Trong block tiếp theo, Bill gọi revealSolution(), cung cấp câu trả lời và mật khẩu mà anh đặt để nhận phần thưởng.
Trong commitSolution(), Bill gửi một chuỗi được mã hóa, giữ lại dữ liệu văn bản gốc chỉ được gửi cho chính anh ấy. Ở bước này, thời gian block gửi cam kết commitTime cũng được ghi lại. Tiếp theo, trong revealSolution(), thời gian block được kiểm tra để ngăn việc chạy trước trong cùng một block. Vì việc gọi revealSolution() yêu cầu gửi câu trả lời bằng văn bản gốc nên bước này nhằm mục đích ngă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 đúng.
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. Thứ nhất, chúng cho phép thực hiện phi tập trung, tự động, đảm bảo tính bảo mật và độ tin cậy của 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 nhưng hợp đồng thông minh cũng phải đố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. Vì vậy, người dùng on-chain cần có một số thói quen. Đầu tiên, người dùng phải luôn lựa chọn cẩn thận các dApp để tương tác và xem xét kỹ code hợp đồng cũng như các quy tắc liên quan. Ngoài ra, nên thường xuyên cập nhật và sử dụng ví an toàn cũng như các công cụ tương tác hợp đồng để giảm thiểu nguy cơ bị hacker tấn công. Hơn nữa, nên lưu trữ tiền ở nhiều địa chỉ để giảm thiểu tổn thất tiềm ẩn do các cuộc tấn công hợp đồng.
Đối với những người chơi trong ngành, việc đảm bảo tính bảo mật và ổn định của hợp đồng thông minh cũng có tầm quan trọng không kém. Ưu tiên hàng đầu 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, rủi ro bảo mật tiềm ẩn. Thứ hai, những người chơi trong ngành nên cập nhật thông tin về những phát triển blockchain mới nhất 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, cũng nên nâng cao giáo dục người dùng và nhận thức về bảo mật trong việc sử dụng đúng 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à người chơi trong ngành, 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 phải luôn lựa chọn cẩn thận các hợp đồng và bảo vệ tài sản cá nhân, trong khi những người trong ngành nên tăng cường kiểm toán hợp đồng, theo kịp các 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.
Tham khảo
Solidity by Example
https://solidity-by-example.org/
Bí quyết về blockchain của SlowMist
Chainlink – Top 10 phương pháp hay nhất về bảo mật DeFi
https://blog.chain.link/defi-security-best-practices/#post-title
WTF – Bảo mật hợp đồng Solidity 104
https://www.wtf.academy/solidity-104/
Các lỗ hổng trong hợp đồng thông minh DeFi ở 4 danh mục với 38 kịch bản
https://www.weiyangx.com/381670.html
OpenZeppelin
https://github.com/OpenZeppelin/
Disclaimer: Đây là bài viết quảng cáo nằm trong chuyên mục Thông cáo Báo chí, không phải là lời khuyên đầu tư. Các bạn cần tìm hiểu kỹ trước khi hành động, chúng tôi không chịu trách nhiệm cho các quyết định đầu tư của bạn.
- CoinEx: Không chỉ là giao dịch – Mối quan hệ tương hỗ giữa trader crypto và sàn giao dịch
- Cuộc cách mạng lấy người dùng làm trung tâm: Hành trình hơn 6 năm của CoinEx
