Machine Translated by Google

KHOA HỌC VÀ CÔNG NGHỆ TSINGHUA

ISSNll1007 -0214 18/03 pp27–

40 DOI: 1 0.
2 6 5 9 9/T ST. 2 0 2 0. 9 0 1 0 0 3 6

Tập 27, Số 1, tháng 2 năm 2022

Thử nghiệm đột biến cho tràn số nguyên trong hợp đồng thông minh Ethereum

Jinlei Sun, Song Huang , Changyou Zheng , Tingyong Wang, Cheng Zong và Zhanwei Hui

Tóm tắt: Tràn số nguyên là một lỗ hổng phổ biến trong Hợp đồng thông minh Ethereum (ESC) và thường gây ra thiệt hại lớn

Thiệt hại kinh tế. Hợp đồng thông minh không thể thay đổi sau khi nó được triển khai trên chuỗi khối và do đó yêu cầu

Thử nghiệm thêm. Kiểm thử đột biến là một phương pháp kiểm thử dựa trên lỗi có thể cải thiện hiệu quả tính đầy đủ của kiểm thử

cho các hợp đồng thông minh. Tuy nhiên, các phương pháp hiện tại không thể thực hiện kiểm tra đột biến một cách hiệu quả dành riêng cho số nguyên

tràn trong ESC. Do đó, bằng cách phân tích tràn số nguyên trong ESC, chúng tôi đề xuất năm toán tử đột biến đặc biệt để

giải quyết lỗ hổng đó về mặt phát hiện đầy đủ trong thử nghiệm ESC. Một nghiên cứu thực nghiệm trên 40 mã nguồn mở

ESC được tiến hành để đánh giá hiệu quả của các toán tử đột biến được đề xuất. Kết quả cho thấy (1) của chúng tôi

toán tử đột biến được đề xuất có thể tái tạo tất cả 179 lỗ hổng tràn số nguyên trong 40 hợp đồng thông minh và

các đột biến được tạo có tỷ lệ vượt qua biên dịch cao và tỷ lệ tạo lỗ hổng tràn số nguyên; Hơn thế nữa,

(2) các đột biến được tạo ra có thể tìm thấy những thiếu sót của các phương pháp thử nghiệm hiện tại đối với lỗ hổng tràn số nguyên,

từ đó hỗ trợ đắc lực để nâng cao tính đầy đủ của bài thi.

Từ khóa: chuỗi khối; Hợp đồng thông minh Ethereum (ESC); tràn số nguyên; thử nghiệm đột biến

1. Giới thiệu Lập trình viên có thể tạo hợp đồng thông minh trên Ethereum.

Hợp đồng thông minh Ethereum (ESC) là một chương trình được
Chuỗi khối là sổ cái chia sẻ phi tập trung kết hợp các khối
triển khai trên chuỗi khối Ethereum, chứa các trạng thái
dữ liệu thành một cấu trúc dữ liệu cụ thể theo trình tự
được xác định trước, quy tắc chuyển đổi, điều kiện thực
thời gian và sử dụng các phương pháp mã hóa để đảm bảo rằng
hiện và logic thực thi. Khi các điều kiện thực thi được
dữ liệu không thể bị giả mạo hoặc giả mạo. Sự xuất hiện đầu
đáp ứng, logic thực thi sẽ tự động được thực hiện.
tiên của chuỗi khối là trong Bitcoin do Nakamoto đề xuất
Hợp đồng thông minh mở rộng khả năng xử lý dữ liệu của
[1]. Trong những năm gần đây, khái niệm chuỗi khối ngày
chuỗi khối. Nhiều hợp đồng thông minh được triển khai trên
càng trở nên phổ biến. Đồng thời, Ethereum[2] đã được sử
Ethereum, do đó đòi hỏi các yêu cầu cao hơn về bảo mật.
dụng rộng rãi hơn trong nhiều lĩnh vực khác nhau, chẳng
Theo nghiên cứu của Nikolic[4], 3686 trong số 3759 hợp đồng
hạn như “Blockchain 2.0”.
thông minh có xác suất chứa lỗ hổng bảo mật là 89%. Nhiều
Ethereum là một chuỗi khối cung cấp ngôn ngữ lập trình
sự cố bảo mật hợp đồng thông minh nghiêm trọng đã xảy ra
hoàn chỉnh Turing, chẳng hạn như Solidity[3] .
trong thế giới thực. Ví dụ, lỗ hổng bảo mật nổi tiếng

Dao[5] vào tháng 6 năm 2016 đã gây thiệt hại 50 triệu đô

Jinlei Sun, Song Huang, Changyou Zheng, Tingyong Wang, và
Cheng Zong đang ở Trường Kỹ thuật Chỉ huy & Kiểm soát, Đại la. Vào tháng 7 năm 2017, hai lỗ hổng bảo mật của ví đa chữ

học Kỹ thuật Lục quân PLA, Nam Kinh 210000, Trung Quốc. E-
mail: jinleisun@yeah.net; hs0317@163.com; zheng chy@163.com;
15061284014@163.com; tông thành @
cnnp.com.cn.
Zhanwei Hui cùng với Viện Đánh giá và Đánh giá
Nghiên cứu, Học viện Khoa học Quân sự, Bắc Kinh 100091, Trung Quốc.
E-mail: hzw 1983821@163.com.
ký Parity[6] đã dẫn đến thiệt hại 30 triệu đô la và 152
triệu đô la. Vào tháng 4 năm 2018, mã thông báo BEC[7] đã
bị đánh cắp và giá trị thị trường 900 triệu đô la của nó
gần như giảm xuống 0 do tràn số nguyên. Xét rằng ESC có
thể liên quan đến một số tiền lớn, một lỗ hổng trong một
dòng mã nhỏ cũng có thể gây ra tổn thất lớn.

Thư từ nên được giải quyết cho ai.

Bản thảo nhận được: 2020-08-08; chấp nhận: 2020-09-09

C (Các) tác giả năm 2022. Các bài báo được xuất bản trên tạp chí truy cập mở này được phân phối theo các điều
khoản của Giấy phép Quốc tế Creative Commons Attribution 4.0 (http://creativecommons.org/licenses/by/4.0/).
Machine Translated by Google
28
Tràn số nguyên là một lỗ hổng phổ biến trong ESC. Kalra và
cộng sự[8] cho thấy 1095 trong số 1564 hợp đồng thông minh
chứa lỗ hổng tràn số nguyên. Hiện tượng này xảy ra vì hai lý
do. Mặt khác , Máy ảo Ethereum (EVM) chỉ có số nguyên 256
bit, trong khi Solidity có nhiều loại số nguyên (số nguyên 8
bit và 16 bit). Do đó, các số nguyên từ các loại Solidity đến
EVM không được ánh xạ chặt chẽ. Mặt khác, Solidity và EVM
không đủ nghiêm ngặt để xử lý các lỗi tràn số nguyên. Khi
xảy ra tràn số nguyên, chương trình không chủ động ném ngoại
lệ mà tiếp tục thực thi đoạn mã tiếp theo.
Do đó, việc kiểm tra lỗi tràn số nguyên trong hợp đồng thông minh
là đặc biệt quan trọng.
Hiện tại, nghiên cứu về kiểm tra lỗ hổng tràn số nguyên
chủ yếu tập trung vào cách phát hiện lỗ hổng trong hợp đồng
thông minh[8]; tuy nhiên, nghiên cứu đánh giá công nghệ thử
nghiệm hợp đồng thông minh vẫn chưa hoàn hảo. Một mặt, hầu
hết các ESC tồn tại ở dạng mã byte; do đó, số lượng mã nguồn
hợp đồng thông minh có thể được sử dụng để thử nghiệm và đánh
giá trong thực tế là hạn chế. Mặt khác, việc gắn nhãn các lỗ
hổng số nguyên theo cách thủ công trong hợp đồng thông minh
hiện tại rất tốn công sức. Tuy nhiên, thử nghiệm đột biến có
thể làm giảm bớt hai tình huống trên một cách hiệu quả. Một
số nhà nghiên cứu [9] cũng đã đề xuất sử dụng thử nghiệm đột
biến để đánh giá các kỹ thuật thử nghiệm và trường hợp thử
nghiệm. Tuy nhiên, không có dấu hiệu hoàn hảo nào tồn tại
đối với các toán tử đột biến tràn số nguyên. Trên cơ sở đó,
nghiên cứu này phân tích các lỗ hổng tràn số nguyên trong hợp
đồng thông minh Solidity được sử dụng rộng rãi nhất trong
Ethereum và đề xuất năm toán tử đột biến. Đầu tiên, chúng
tôi tóm tắt ba loại lỗi tràn số nguyên tồn tại trong hợp đồng
thông minh: số học, cắt ngắn và tràn số đã ký. Thứ hai, năm
toán tử đột biến đặc biệt được đề xuất cho ba loại lỗi số
nguyên ở trên. Các toán tử này bao gồm các toán tử đột biến
đã tồn tại trong các thử nghiệm đột biến truyền thống và
những toán tử được đề xuất trong nghiên cứu này.
Một nghiên cứu thực nghiệm đã được tiến hành trên 40 ESC
mã nguồn mở . Kết quả cho thấy (1) các toán tử đột biến được
đề xuất của chúng tôi có thể tái tạo tất cả 179 lỗ hổng tràn
số nguyên trong 40 hợp đồng thông minh ban đầu và các đột
biến được tạo có tỷ lệ vượt qua biên dịch và tỷ lệ tạo lỗ
hổng tràn số nguyên cao; hơn nữa, (2) các đột biến do toán tử
đột biến tạo ra có thể tìm ra những thiếu sót của các phương
pháp kiểm tra hiện tại đối với lỗ hổng tràn số nguyên, do đó
cung cấp hỗ trợ hiệu quả để cải thiện tính đầy đủ của kiểm
tra.
Khoa học và Công nghệ Thanh Hoa, tháng 2 năm 2022, 27(1): 27–
40
Những đóng góp chính của nghiên cứu này như sau:
Chúng tôi phân tích các lỗ hổng tràn số nguyên tồn tại trong
hợp đồng thông minh và đề xuất năm toán tử đột biến đặc biệt cho
lỗi tràn số nguyên trong ESC.
Dựa trên các toán tử đột biến được đề xuất, chúng tôi triển
khai một công cụ đột biến tràn số nguyên để có thể thực hiện tự
động việc tiêm đột biến cho tràn số nguyên.
Chúng tôi thu thập và gắn nhãn 40 hợp đồng thông minh
nguồn mở có lỗ hổng tràn số nguyên, tạo ra 2099 đột biến và
tiến hành nghiên cứu thực nghiệm về chúng. Kết quả cho thấy
rằng các nhà khai thác của chúng tôi không chỉ có thể tạo ra
các đột biến hữu ích mà còn cung cấp hỗ trợ hiệu quả để cải
thiện tính đầy đủ của thử nghiệm ESC. Công cụ và dữ liệu trên
có sẵn tại GitHub[10] .
Phần còn lại của bài viết này được tổ chức như sau: Phần 2
cung cấp thông tin cơ bản về ESC và thử nghiệm đột biến và
mô tả các lỗ hổng tràn số nguyên chính trong ESC. Phần 3 cung
cấp công việc liên quan và Phần 4 mô tả các toán tử đột biến
của chúng tôi trong thử nghiệm đột biến ESC. Phần 5 trình bày
thiết kế và phân tích của nghiên cứu thực nghiệm được tiến
hành. Phần 6 cung cấp các mối đe dọa đối với tính hợp lệ.
Phần 7 kết thúc nghiên cứu và trình bày các kế hoạch cho công
việc trong tương lai.
2 bối cảnh
2.1 Hợp đồng thông minh Ethereum
Hợp đồng thông minh, được đề xuất bởi Szabo[11] vào năm 1996,
gói gọn các trạng thái và quy tắc chuyển đổi được xác định
trước, đồng thời kích hoạt các kịch bản thực hiện hợp đồng
và hoạt động phản hồi trong các tình huống cụ thể. Khi các
điều kiện thực thi được thỏa mãn, các hợp đồng thông minh sẽ
tự động được thực thi và kết quả thực thi được tạo ra theo
mã trong hợp đồng.
Chuỗi khối phù hợp với các hợp đồng thông minh do tính phi
tập trung, tính bất biến và khả năng truy xuất nguồn gốc của nó.
Hiện tại, nhiều hệ thống chuỗi khối (chẳng hạn như Bitcoin[1]
và Ethereum[2]) hỗ trợ công nghệ hợp đồng thông minh.
Với một ngôn ngữ lập trình hoàn chỉnh và một loạt các công cụ xây
dựng phức tạp, Ethereum đã trở thành một nền tảng blockchain hấp
dẫn để xây dựng các ứng dụng phi tập trung khác nhau.
Chuỗi khối Ethereum có hai loại tài khoản: bên ngoài và
hợp đồng. Tài khoản bên ngoài được tạo
bởi các cá nhân và được kiểm soát bởi khóa bí mật, trong khi
tài khoản hợp đồng được tạo khi hợp đồng được triển khai và
chủ yếu được kiểm soát bởi mã hợp đồng. Tài khoản bên ngoài
và hợp đồng có thể thực hiện các hoạt động, chẳng hạn như
Machine Translated by Google

Jinlei Sun và cộng sự: Thử nghiệm đột biến cho tràn số nguyên trong hợp đồng thông minh Ethereum 29

chuyển Ether và gọi hợp đồng, bằng cách gửi các giao dịch được sử dụng rộng rãi trong nghiên cứu kiểm thử phần mềm truyền thống[16] .

theo địa chỉ hợp đồng. ESC thường dễ bị tổn thương và khó sửa đổi sau khi triển

Hiện tại, ngôn ngữ lập trình hợp đồng thông minh phổ khai. Do đó, cần phải thử nghiệm thêm trước khi ESC được

biến nhất trong Ethereum là Solidity; do đó, đối tượng triển khai trên chuỗi. Hơn nữa, thử nghiệm đột biến có thể

nghiên cứu của nghiên cứu này là ESC được viết bằng là một kỹ thuật hiệu quả trong việc thúc đẩy chất lượng của

Solidity. Solidity là một ngôn ngữ hoàn chỉnh Turing tương thử nghiệm ESC.

tự như JavaScript. Các lập trình viên sử dụng Solidity để

2.3 Lỗ hổng tràn số nguyên trong ESC
viết hợp đồng thông minh và biên dịch chúng thành mã byte
Kalra và cộng sự[8] đã chỉ ra rằng tràn số nguyên là một
EVM; sau đó, họ triển khai các hợp đồng thông minh trên
trong những lỗ hổng thường gặp nhất trong hợp đồng thông minh.
chuỗi khối Ethereum bằng cách gửi các giao dịch.
Kết quả nghiên cứu của họ cho thấy 1095 trong số 1564
Các lỗ hổng bảo mật hợp đồng thông minh thường xuyên xảy
hợp đồng thông minh chứa lỗ hổng tràn số nguyên.
ra do một số lý do. Đầu tiên, ngôn ngữ lập trình của hợp
Các sự kiện bảo mật hợp đồng thông minh BEC, SMT và FNT nổi
đồng thông minh (ví dụ: Solidity) tương đối mới và do đó có
tiếng là do lỗ hổng tràn số nguyên gây ra.
thể có một số thiếu sót. Thứ hai, các lập trình viên không
Tràn số nguyên trong Solidity tương tự như tràn số nguyên
quen thuộc với ngôn ngữ Solidity và khó tránh khỏi một số
truyền thống[17], có thể chia thành ba loại: tràn số học,
lỗi khi viết mã hợp đồng thông minh. Thứ ba, hợp đồng thông
cắt bớt và tràn có dấu.
minh không thể thay đổi sau khi được triển khai trên chuỗi
2.3.1 Tràn số học
khối. Ngay cả khi các lỗ hổng được tìm thấy trong hợp đồng,

hợp đồng không thể được sửa chữa bằng cách vá. Tràn số học là loại lỗ hổng tràn số nguyên phổ biến nhất.

Nguyên nhân chủ yếu là do không kiểm tra ranh giới khi thực

hiện các phép toán số học, có thể được chia thành tràn và
2.2 Thử nghiệm đột biến
tràn.
Kiểm thử đột biến là một kỹ thuật kiểm thử phần mềm dựa

trên lỗi [12]. Hai giả định được đưa ra trong thử nghiệm
Tràn xảy ra khi việc gán một biến số nguyên
đột biến: giả thuyết về lập trình viên có thẩm quyền[13]
vượt quá giới hạn trên của nó. Ví dụ: trong đoạn
và hiệu ứng khớp nối[14] . Cái trước có nghĩa là lập trình
mã tràn SWC-101 được hiển thị trong Hình 2, số
viên mã hóa tốt nhất có thể và sản phẩm mã hóa gần đúng.
dư biến là một số nguyên không dấu 256 bit. Khi
Điều đó có nghĩa là các lỗ hổng trong mã rất tinh vi và do
tiền gửi giá trị đầu vào lớn và tổng của số dư
đó thử nghiệm đột biến có thể mô phỏng các lỗ hổng mã hóa
lớn hơn 2256, nó sẽ khiến số dư bị tràn và trở
bằng cách thay đổi một phần nhỏ của mã. Cái sau giả định
thành một giá trị tương đối nhỏ.
rằng các lỗ hổng phức tạp được xếp chồng lên nhau bởi các
Khi việc gán một biến số nguyên vượt quá giới hạn dưới
lỗ hổng đơn giản và có thể tìm thấy các lỗ hổng phức tạp
của phạm vi biểu diễn của nó, thì xảy ra tràn dưới. Toán tử
bằng cách phát hiện các lỗ hổng đơn giản; nghĩa là, chỉ có
số học chính gây ra dòng chảy tràn là phép trừ. Ví dụ:
một lỗ hổng duy nhất trong các dị nhân là có ý nghĩa. Quy
trong đoạn mã dòng dưới SWC 101 được hiển thị trong Hình
trình thử nghiệm đột biến cho hợp đồng thông minh được hiển
3, số đếm là
thị trong Hình 1.

1 hợp đồng Simple Add f uint

Kiểm thử đột biến có thể đo lường chất lượng của các trường hợp kiểm 2 public balance = 10 000 000; chức

thử hoặc các kỹ thuật kiểm thử, chẳng hạn như kiểm thử mờ [15], và đã được 3 năng thêm (tiền gửi uint256 ) số dư f

4 công cộng + = tiền gửi; // Tràn ra

5 g

6g _

Hình 2 Đoạn mã tràn SWC-101.

1 hợp đồng Simple Min f uint

2 public count = 1; hàm

3 tối thiểu (đầu vào uint256 ) công khai f

4 đếm -= đầu vào; // Dòng chảy ngầm

5 g

6g _

Hình 1 Quy trình kiểm tra đột biến. Hình 3 Đoạn mã chảy tràn SWC-101.
Machine Translated by Google

30 Khoa học và Công nghệ Thanh Hoa, tháng 2 năm 2022, 27(1): 27–
40

một số nguyên không dấu 256-bit. Khi giá trị đầu vào lịch sử hơn 40 năm. Kiểm thử đột biến được sử dụng trong các

đầu vào lớn hơn số đếm, nó sẽ khiến số đếm bị tràn và loại kiểm thử phần mềm khác nhau, chẳng hạn như Java[21] ,

trở thành một giá trị tương đối lớn. C#[22], và C++[23] trong các ngôn ngữ hướng đối tượng[24–

2.3.2 Tràn cắt ngắn 26]; Haskel[27] trong các ngôn ngữ lập trình chức năng[28];

.
và di động[29, 30] và thử nghiệm ứng dụng web[31, 32]
Các số nguyên trong Solidity nằm trong khoảng từ 8 đến 256 bit
Wu và cộng sự.[9] lần đầu tiên giới thiệu thử nghiệm đột biến
và tăng theo gia số 8 bit. Việc gán một số nguyên có độ rộng
để thử nghiệm hợp đồng thông minh . Mười lăm toán tử đột biến
bit nhỏ cho một số nguyên có độ rộng lớn không gây tràn; ngược
mới được thiết kế cho ESC và công cụ kiểm tra đột biến,
lại, việc gán một số nguyên có độ rộng bit lớn cho một số nguyên
MuSC[33], đã được triển khai. Hartel và Schumi [34] đã thực
có độ rộng bit nhỏ dẫn đến việc cắt ngắn và giá trị nhỏ hơn. Ví
hiện thử nghiệm đột biến trên một hợp đồng trò chơi trực tuyến
dụ: trong đoạn mã sau trong Hình 4, lỗi tràn do cắt bớt xảy ra
và đề xuất một toán tử đột biến Mothra tiêu chuẩn và bốn toán
khi msg.value, ban đầu là uint256, bị cắt bớt thành uint64 ở
tử đột biến dành riêng cho Solidity. Kết quả cho thấy các toán
Dòng 3, dẫn đến số dư[msg.sender] nhỏ hơn nhiều so với msg.value .
tử đột biến đặc biệt hiệu quả hơn tiêu chuẩn.

Trong Tài liệu tham khảo [35], 10 loại toán tử đột biến đã được

đề xuất cho ESC và các toán tử này được triển khai trên cơ sở
2.3.3 Tràn có dấu Tràn có
của UniversalMutator.
dấu xảy ra do sự khác biệt giữa kiểu biến đích và kiểu giá trị
3.2 Thử nghiệm hợp đồng thông minh
được gán, bao gồm hai trường hợp. Một là chuyển đổi số nguyên

có dấu thành số nguyên không dấu. Bit cao nhất của một số nguyên Oyente[36] là một trong những công cụ phân tích hợp đồng thông

có dấu là bit dấu. Nếu một số có dấu được gán cho một số nguyên minh sớm nhất. Nó thực hiện việc thực thi các hợp đồng thông

không dấu có cùng kích thước, nó sẽ tràn sang một số dương lớn minh một cách tượng trưng ở cấp mã byte. Dựa trên Oyente,

hơn. Một số khác bị tràn khi chuyển đổi số nguyên không dấu Osiris[37] đã tiến hành nghiên cứu về lỗ hổng tràn số nguyên

thành số nguyên có dấu. Nếu một số nguyên không dấu lớn hơn trong hợp đồng thông minh và sử dụng công nghệ thực thi ký hiệu

được gán cho một số nguyên có dấu có cùng độ dài, thì số đó có để phát hiện ba loại tràn số nguyên. Maian[4] có thể tìm các

thể bị chuyển thành số âm và gây ra lỗi. Trong đoạn mã sau ở ESC tự hủy và rút tiền từ bất kỳ địa chỉ nào và phát hiện các

Hình 5, giá trị tham số đầu vào của hàm trasferFrom thuộc loại ESC không có chức năng thanh toán.

int, được chuyển đổi thành uint trong lần sử dụng tiếp theo và Một số nghiên cứu đã phân tích hợp đồng thông minh từ góc độ

có thể khiến cho số dư[ thành] thêm một giá trị lớn hơn và gây xác minh chính thức. Bhargavan và cộng sự[38] đã sử dụng ngôn

ra lỗ hổng bảo mật. ngữ chức năng F* để phân tích SMT và đề xuất các công cụ phân

tích cho mã nguồn và mã byte.

Hirai[39] đã sử dụng Isabelle/HOL Proof Assistant để lập mô

hình Ethereum về mặt ngữ nghĩa và xác minh một hợp đồng thông
3 Công việc liên quan
minh cụ thể có tên là Deed. ZEUS[8] có thể nhanh chóng xác minh

3.1 Thử nghiệm đột biến Thử các hợp đồng bảo mật thông qua các công nghệ, chẳng hạn như

giải thích trừu tượng, kiểm tra mô hình biểu tượng và các điều
nghiệm đột biến lần đầu tiên được đề xuất bởi DeMillo và cộng sự.
khoản sừng bị ràng buộc.
[13] vào năm 1978. Sau khi phát triển liên tục [18–20], nó đã có
Ngoài ra, nhiều học giả đã kiểm tra tính bảo mật của hợp

đồng thông minh từ góc độ phân tích tĩnh. Securify[40] sử dụng

1 cân bằng ánh xạ (địa chỉ=>uint64) ; 2
bộ giải Souffle Datalog để phân tích tĩnh mã byte EVM và suy ra

thông tin ngữ nghĩa chính xác liên quan đến hợp đồng.
3 số dư[msg.sender] = uint64(msg.value) 4

SmartCheck[41] chuyển đổi mã nguồn thành dạng biểu diễn trung

Hình 4 Ví dụ về tràn cắt ngắn.
gian dựa trên XML và sử dụng chế độ XPath để kiểm tra.

1 hàm transferFrom(địa chỉ tới, giá trị int ) SolidityCheck[42] định dạng mã, lọc từ khóa, sau đó sử dụng các
2 biểu thức thông thường để phát hiện lỗ hổng trong mã được lọc
3 số dư[to]=số dư[to].add(uint(value)) hoặc chèn mã để ngăn chặn sự xuất hiện của lỗ hổng.
4

Hình 5 Ví dụ về tràn có dấu.

Machine Translated by Google

Jinlei Sun và cộng sự: Thử nghiệm đột biến cho tràn số nguyên trong hợp đồng thông minh Ethereum 31

Slither[43] là một khung phân tích tĩnh ba loại toán tử tương ứng với thư viện SafeMath bị thiếu
chuyển đổi một hợp đồng thông minh đáng tin cậy thành một hợp đồng trung gian hoặc không được sử dụng, câu lệnh kiểm tra sai và câu lệnh

đại diện được gọi là SlithIR; nó áp dụng các kỹ thuật phân tích kiểm tra bị thiếu tương ứng.

chương trình, chẳng hạn như luồng dữ liệu và theo dõi ô nhiễm, 4.1.1 Thay thế Hoạt động SafeMath (SOR)
để trích xuất và tinh chỉnh thông tin. Durieux và cộng sự.[44]
Thư viện SafeMath đã viết lại các toán tử số học như C; ; ;
đã sàng lọc các công cụ phân tích hợp đồng thông minh hiện có
=; và % và đã thêm kiểm tra trong quá trình hoạt động để
và chạy chín công cụ trên 69 hợp đồng thông minh với 115 lỗ hổng.
ngăn tràn số nguyên.
Kết quả cho thấy rằng tổng tỷ lệ phát hiện của thông minh
Không làm mất tính tổng quát, chúng tôi giả định rằng thư
phát hiện lỗ hổng hợp đồng của các công cụ trên là 42%
viện SafeMath được giới thiệu trong hợp đồng thông minh
với một số không gian để cải thiện.
không có lỗ hổng số nguyên và các hoạt động sử dụng hàm thư
Về mặt thử nghiệm động, Jiang và cộng sự.[45] đã đề xuất
viện trong hợp đồng thông minh sẽ không gây tràn số nguyên.
ContractFuzzer, khuôn khổ kiểm tra lỗ hổng bảo mật đầu tiên
Tuy nhiên, người lập trình có thể không sử dụng đúng các
cho các hợp đồng thông minh Ethereum. Nó tạo đầu vào thử
hàm trong thư viện SafeMath trong quá trình lập trình. Ví
nghiệm tuân theo cú pháp cuộc gọi của hợp đồng gọi điện,
dụ: mặc dù thư viện SafeMath được giới thiệu, các toán tử
xác định các dự đoán thử nghiệm mới và sử dụng EVM giám sát
số học có thể được sử dụng trực tiếp trong phép toán. Toán
thông tin thực thi hợp đồng thông minh để phát hiện các lỗ
tử SOR mô phỏng điều này; nó biến hàm SafeMath trong hợp
hổng. ContraMaster[46] là một khung thử nghiệm động hợp
đồng thông minh thành một toán tử số học, và biểu diễn và
đồng thông minh dựa trên tiên tri thử nghiệm mới. Nó hướng
mô tả cụ thể của nó được thể hiện trong Bảng 1.
dẫn quy trình fuzzing thông qua luồng dữ liệu, luồng điều

khiển và phân tích trạng thái hợp đồng. Và nó có thể đánh

Hình 6 cho thấy một ví dụ về toán tử SOR thay đổi hợp
giá kết quả phù hợp với sự bất biến giữa số tiền được ghi
đồng StandardToken, định nghĩa thư viện SafeMath để ngăn
và thực tế trong thông minh
lỗi tràn số nguyên. SORsub thay thế hoạt động được thực
hợp đồng. ReGuard[47] phát triển một bộ phân tích dựa trên mờ
hiện bởi hàm thư viện SafeMath.sub() được sử dụng trong
để tự động phát hiện các lỗ hổng truy cập lại. Đặc biệt, nó
Dòng 17 với giá trị đầu vào toán tử số học lớn hơn
thực hiện fuzzing trên các hợp đồng thông minh bằng cách lặp “”
balances[msg.sender], như được hiển thị trong Dòng 20. Nếu

lại các giao dịch ngẫu nhiên nhưng khác nhau.

khi đó lỗ hổng bảo mật tràn có thể xảy ra trong Dòng 20; do

đó, balances[msg.sender] được gán với một giá trị lớn.

4 Số nguyên hợp đồng thông minh Ethereum
Toán tử đột biến tràn
4.1.2 Xóa Tuyên bố Điều kiện (CSD)
Trong phần này, chúng tôi đề xuất một loạt các toán tử đột
Ngoài việc sử dụng thư viện SafeMath, người lập trình cũng
biến cho phép tính số học, cắt bớt và ký tràn trong hợp
có thể ngăn chặn tràn số học bằng cách thiết lập kiểm tra
đồng thông minh Solidity.
điều kiện. Các câu lệnh điều kiện này trong Solidity thường

4.1 Toán tử đột biến tràn số học ở ba dạng: yêu cầu (), khẳng định () và nếu
các câu lệnh.
Sử dụng thư viện SafeMath hoặc thêm các điều kiện kiểm tra
Các nghiên cứu trước đây [9, 35] đã đề xuất các toán tử
trong các phép tính số học có thể ngăn chặn sự xuất hiện
đột biến xóa các câu lệnh require() và assert().
của tràn số học. Tuy nhiên, những phương pháp này là không
Tuy nhiên, không phải tất cả sự vắng mặt của các câu lệnh
đủ vì những lý do sau đây. Đầu tiên, thư viện SafeMath
require() và assert() sẽ gây ra lỗi tràn số học. Giải pháp
không được giới thiệu trong tất cả các hợp đồng thông minh.
được đề xuất trong nghiên cứu này là so khớp thông qua các
Torres và cộng sự[37] đã phân tích 495 hợp đồng thông minh token trên

Ethereum và thấy rằng 32% trong số họ không sử dụng biểu thức chính quy và tìm các câu lệnh require() và

assert() ngăn tràn số học.

Thư viện SafeMath. Thứ hai, mặc dù một số hợp đồng thông

minh sử dụng thư viện SafeMath, lập trình viên cũng có thể
Bảng 1 Toán tử thay thế phép toán SafeMath.
sử dụng trực tiếp các toán tử số học thay vì các hàm
Nhà điều hành Sự miêu tả
SafeMath do sơ suất, như ví dụ được mô tả trong CVE-2018-10299 SORadd Thay SafeMath.add() bằng “+”
[48]. Thứ ba, câu kiểm tra sai cũng có thể gây ra lỗi này. SORsub Thay SafeMath.sub() bằng “”
SORmul Thay SafeMath.mul() bằng “”

Dựa trên phân tích trên, chúng tôi đề xuất ba loại toán SORdiv Thay SafeMath.div() bằng “=”

tử đột biến cho các phép toán số học. Những cái này SORmod Thay SafeMath.mod() bằng “%”
Machine Translated by Google

32 Khoa học và Công nghệ Thanh Hoa, tháng 2 năm 2022, 27(1): 27–
40

1 hợp đồng tràn Thêm f

1 thư viện SafeMath f

2 hàm sub(uint256 a, uint256 b) trả về 2 dư công uint = 10000000;

3 uint256 f
3 chức năng thêm ( tiền gửi uint256) công khai f

4 4 //yêu cầu (số dư <số dư + tiền gửi)

yêu cầu (a > b);

5 uint256 c D a bI 5 số dư tiền gửi CD; // Tràn ra

6 trở lại cI
6 g

7 7g _
g

số 8
Hình 7 Đột biến CSD cho Tràn thêm.
9g _

10 hợp đồng Overflow Add bởi toán tử CSdr. Sau đó

11 hợp đồng StandardToken f khớp câu lệnh request() trên Dòng 4 cho đến hết
12 ánh xạ (địa chỉ => uint256) số dư;
biểu thức chính quy, CSDr sẽ xóa nó. Tràn số nguyên
13 chuyển chức năng (địa chỉ đến, giá trị int)
có thể xảy ra ở Dòng 5 trong khi thao tác “CD”.
14 lợi nhuận công khai (bool)f
15 yêu cầu (đến != địa chỉ (0)); 4.1.3 Thay đổi Tuyên bố Điều kiện (CSC)

16 // Thay đổi ”SafeMath.sub()” thành ”–” Việc thiết lập các điều kiện không chính xác cũng có thể dẫn đến
17 //balances[msg.sender] = SafeMath.sub( tràn số học. Do đó, một toán tử đột biến cho
18 // số dư [msg.sender], giá trị) sửa đổi câu điều kiện phải được thiết kế.
19 số dư[msg.sender]=
Các nghiên cứu trước đây [9, 35] cũng đã đề xuất các toán tử
20 số dư[msg.sender]–
giá trị;
làm biến chất các toán tử quan hệ >, , <, , Tuy nhiên, vân vân.

21 balances[to]=SafeMath.add(số dư[to],giá trị);

không phải tất cả việc sử dụng sai toán tử quan hệ đều dẫn đến
22 Chuyển(tin nhắn.người gửi, tới, giá trị);
23 trả về đúng;
để tràn số nguyên. Chỉ khi toán tử quan hệ trong

24g _
câu điều kiện ngăn tràn số nguyên là

25g _ sử dụng không chính xác có thể xảy ra tràn số nguyên. Vì thế,

26 tương tự như CSD, trước tiên chúng tôi sử dụng biểu thức chính quy

để CSC khớp với các toán tử quan hệ trong

Hình 6 Đột biến SOR cho StandardToken.
Tràn số học thường xảy ra trong quá trình tính toán số học
hoạt động, và tuyên bố điều kiện để ngăn chặn
tràn số học phải chứa các toán hạng trong
biểu thức số học. Đầu tiên chúng tôi phù hợp với cơ bản
toán tử số học nhị phân (C; ; ; =; %) và toán tử gán cắt ngắn
(CD; D; D; % D; = D),
và sau đó là các tham số xuất hiện trong khớp
câu điều kiện ngăn tràn số nguyên trong
mã và sau đó thực hiện thao tác nghịch đảo. Tên
và mô tả được thể hiện trong Bảng 3.
Một ví dụ về toán tử CSC được hiển thị trong Hình 8.
“<” ở Dòng 3 được đổi thành “>” ở Dòng 4, do đó
gây ra lỗ hổng tràn số nguyên trong Dòng 5.
4.2 Toán tử đột biến tràn cắt xén

biểu thức số học được kiểm tra lại. Nếu giống nhau Ngôn ngữ Solidity hỗ trợ nhiều loại số nguyên

các tham số xuất hiện trong các câu lệnh điều kiện, chẳng hạn từ 8 đến 256 bit, với kích thước bước thay đổi là 8 và

như yêu cầu (), trong cùng một chức năng, thì điều kiện
Bảng kích thước đầy đủ
tuyên bố được coi là một điều kiện ngăn chặn tràn
Nhà điều hành Sự miêu tả
phát biểu của công thức trên.
CSCa Thay đổi câu khẳng định()
Các toán tử đột biến CSDa, CSDr và CSDi CSCr Thay đổi câu yêu cầu ()
xóa các câu lệnh khẳng định (), yêu cầu () và nếu khớp CSCI Thay đổi nếu câu

bởi biểu thức chính quy. Tên và mô tả của

toán tử đột biến được thể hiện trong Bảng 2.
1 hợp đồng Simple Sub f
Ví dụ trong Hình 7 cho thấy quá trình biến đổi 2 hàm phụ(uint256 a, uint256 b) internalf

3 //yêu cầu(b<a);
Bảng kích thước đầy đủ
4 require(b>a);//thay đổi các toán tử quan hệ
Nhà điều hành Sự miêu tả
5 trả lại ab; // Dòng chảy ngầm
CSDA Xóa câu khẳng định()
6 g
CSDr Xóa câu yêu cầu ()
7g _
CSDi Xóa nếu câu
Hình 8 Đột biến CSC cho Sub đơn giản.
Machine Translated by Google

Jinlei Sun và cộng sự: Thử nghiệm đột biến cho tràn số nguyên trong hợp đồng thông minh Ethereum 33

hỗ trợ các loại địa chỉ. Lỗi tràn cắt ngắn trong hợp đồng Hình 10. Tham số đầu vào lượng của hàm rút lạiOnce() có

thông minh Solidity thường do chuyển đổi số nguyên có độ kiểu int và Dòng 6 của mã chuyển đổi nó thành kiểu uint khi

rộng bit thành số nguyên có độ rộng bit. nó được sử dụng. Sau đó, tràn đã ký xảy ra. Nó có thể khiến

Chỉ cần chuyển đổi trực tiếp mã định danh loại có độ hàm transfer() gửi thêm ête tới msg.sender.

rộng bit thành loại có độ hẹp bit có thể không trực tiếp

gây ra lỗi tràn cắt ngắn. Do đó, chúng tôi thiết kế toán tử
4.4 Tóm tắt các toán tử
Thay đổi loại biến (VTC) để chuyển đổi loại chiều rộng bit
Năm toán tử đột biến trong nghiên cứu này khác với các toán
được xác định ban đầu thành loại hẹp bit khi sử dụng. Toán
tử trong các nghiên cứu trước đây [9, 33, 34]. Các toán tử
tử được thể hiện trong Bảng 4.
này có thể mô phỏng chính xác các lỗi tràn số nguyên khác nhau.
Một ví dụ về toán tử VTC được hiển thị trong Hình 9.
Trong số các toán tử trong nghiên cứu này, SOR được đề xuất
Biến “tiền gửi” ban đầu có kiểu uint, nghĩa là kiểu số
lần đầu tiên để mô phỏng các lỗi tràn số học gây ra bởi
nguyên của uint256. Khi nó được tính toán trong hàm add(),
việc sử dụng không đúng chức năng SafeMath trong ESC. Mặc
nó được chuyển thành uint64. Nếu tiền gửi có giá trị tương
dù các toán tử, chẳng hạn như CSD, CSC, VTC và SUR/USR,
đối lớn, thì có thể xảy ra tình trạng tràn do cắt ngắn.
cũng được sử dụng trong thử nghiệm đột biến truyền thống,
4.3 Toán tử đột biến tràn có dấu chúng tôi đã thực hiện các cải tiến để cho phép toán tử này

Các kiểu số nguyên trong ngôn ngữ Solidity được chia thành được sử dụng riêng trong thử nghiệm đột biến ESC. CSD và

kiểu số nguyên có dấu int và kiểu số nguyên không dấu uint. CSC sử dụng các biểu thức chính quy để tìm các câu lệnh có

Nếu giá trị đã được gán cho kiểu số nguyên có dấu int lại điều kiện, được sử dụng để ngăn chặn các lỗ hổng tràn số

được chuyển đổi thành kiểu số nguyên không dấu uint, thì nguyên, sau đó thực hiện xóa và sửa đổi để mô phỏng các lỗi

tràn số có dấu sẽ xảy ra và ngược lại. Tương tự như lỗi tràn số học; Các toán tử VTC và SUR/USR tìm định nghĩa của

tràn do cắt bớt, việc thay đổi trực tiếp định nghĩa kiểu một biến và sau đó sửa đổi kích thước và ký hiệu của nó để

trong mã hoàn toàn không gây ra lỗi tràn đã ký. Do đó, mô phỏng quá trình cắt bớt và tràn ký hiệu.

chúng ta cần chuyển đổi giá trị ban đầu được xác định là số Những khác biệt của các toán tử đột biến được đề xuất được

nguyên có dấu int thành số nguyên không dấu uint và ngược mô tả trong Bảng 6.

lại. Điều quan trọng là phải thay đổi loại.

5 Nghiên cứu Thực nghiệm
Do đó, chúng tôi thiết kế hai toán tử đột biến cho tràn

đã ký. Toán tử SUR chuyển đổi số nguyên có dấu int thành số Trong phần này, chúng tôi tiến hành nghiên cứu thực nghiệm
nguyên không dấu uint và USR chuyển đổi số nguyên không dấu để đánh giá các toán tử đột biến tràn số nguyên được đề xuất
uint thành số nguyên có dấu int. Tên và mô tả của các nhà

khai thác được hiển thị trong Bảng 5. 1 hàm rútOnce ( số tiền int) public f 2

if (số tiền>1 ether jj được chuyển[msg.sender])f

3 revert();
Một ví dụ về toán tử SUR được hiển thị trong
4
Bảng 4 Toán tử đột biến tràn cắt ngắn. 5 g // Thay đổi int “số tiền” thành

Nhà điều hành Sự miêu tả 6 uint msg.sender.transfer(uint(số

VTC Thay đổi loại biến tiền)); đã chuyển[msg.sender]=true;

6 7 gam

1 co Tru Add f 2 uint Hình. 10 Đột biến SUR để rút tiền Một lần.
public balance = 1; chức năng
Bảng kích thước đầy đủ
3 thêm (tiền gửi uint256 ) công khai yêu
Toán tử Mô tả SOR Lần đầu tiên được đề xuất
4 cầu (số dư < số dư + tiền gửi); số
trong công việc này.
5 dư = uint64(tiền gửi) + (số dư); g
CSD Xóa câu điều kiện dùng để
6
ngăn tràn số nguyên trong ESC.
7g _
CSC Thay đổi câu điều kiện được sử dụng để ngăn tràn số
Hình 9 Đột biến VTC cho Tru Add. nguyên trong ESC.

Bảng kích thước đầy đủ VTC Thay đổi kích thước của một biến khi nó được sử dụng sau
nó được định nghĩa trong ESC.
Mô tả nhà điều hành
SUR SUR/USR Thay đổi dấu của một biến khi nó được sử dụng sau
Đã ký thay thế chưa ký
nó được định nghĩa trong ESC.
USR Unsigned để thay thế đã ký
Machine Translated by Google

34 Khoa học và Công nghệ Thanh Hoa, tháng 2 năm 2022, 27(1): 27–
40

bên trên. Sau đây, các câu hỏi nghiên cứu được đặt ra trước tiên 5.2 Dữ liệu thực nghiệm

nâng lên. Sau đó, dữ liệu thực nghiệm và thực nghiệm

Các dữ liệu thử nghiệm có thể được chia thành hai phần.
quá trình được mô tả. Cuối cùng, kết quả thực nghiệm
Phần đầu tiên là một loạt các ESC dùng để minh họa số nguyên
được trình bày và phân tích. tràn lỗ hổng. Chúng tôi chọn 10 trong số họ từ

5.1 Câu hỏi nghiên cứu bộ dữ liệu SBCURATED trong Ref. [14]. Vị trí và

loại lỗ hổng trong các hợp đồng này được biết đến và
Mục tiêu của phần này là để trả lời những điều sau đây
thường được sử dụng trong kiểm tra tính hợp lệ của phân tích ESC
câu hỏi nghiên cứu:
công cụ. Phần thứ hai là ESC đã được triển khai trên
RQ1: Toán tử đột biến có hiệu quả không
Chuỗi khối Ethereum. Tham khảo [49] liệt kê chín loại
đột biến ESC? Trong quá trình thử nghiệm ESC,
số lượng mã nguồn của hợp đồng thông minh bị lỗi về lỗ hổng tràn số nguyên trong Mã thông báo ERC20. TRONG

mỗi danh mục, một số hợp đồng thông minh được liệt kê. Các
có giới hạn. Một trong những mục tiêu của chúng tôi là có thể biến đổi
phần đầu tiên của tập dữ liệu là mã mẫu được sử dụng để hiển thị
hợp đồng thông minh thông qua các nhà khai thác được đề xuất trong này
lỗ hổng; hầu hết chúng đều tương đối ngắn.
nghiên cứu và mô phỏng các loại lỗi tràn số nguyên trong
ESC. Do đó, chúng tôi thêm phần thứ hai để tăng cường

tính xác thực của dữ liệu thực nghiệm và độ tin cậy

RQ2: Liệu các đột biến được tạo ra bởi
của kết quả thí nghiệm. Đồng thời, chúng tôi chỉ
các nhà khai thác được đề xuất đánh giá hiệu quả các trường hợp thử nghiệm hoặc

chọn tối đa năm hợp đồng thông minh từ mỗi danh mục
công cụ kiểm tra? Thử nghiệm đột biến có thể đánh giá và thúc đẩy

hiệu suất của các trường hợp thử nghiệm hoặc công cụ thử nghiệm bằng cách tạo
(có thể ít hơn 5 trong một số danh mục) do

sự tương đồng lớn giữa các loại lỗ hổng và

đột biến. Mục tiêu khác của nghiên cứu này là có thể
mã số hợp đồng trong từng danh mục; chúng tôi thu được 30 ERC20
đo lường hiệu suất của các phương pháp hoặc công cụ hiện có
Mã thông báo hợp đồng thông minh là bộ dữ liệu thứ hai.
trong thử nghiệm tràn số nguyên ESC thông qua đề xuất
Các chi tiết của ESC đã chọn được hiển thị trong Bảng 7. Chúng tôi
người vận hành.

Bảng kích thước đầy đủ

Con số Số ESC Số lượng

Loại Sự miêu tả của tràn số nguyên mã ESC

ESC lỗ hổng dòng

Kích hoạt bỏ qua tràn bằng cách nhập các tham số lớn hơn và
hàng loạtTransfer-tràn 5 10 1330
sử dụng hàm batchTransfer() để chuyển hàng loạt.

Tràn xảy ra khi cộng và trừ tổngCung cấp

tràn tổng cung 4 33 978
của tổng số lượng mã thông báo, tạo ra một giá trị không mong muốn.

Khi thực hiện chuyển giao và các hoạt động khác trong

xác minh không hợp lệ do tràn hợp đồng, số dư sẽ được xác minh và xác minh 2 2 604

có thể được bỏ qua để đạt được chuyển giao bất hợp pháp thông qua tràn.

Người sở hữu xây dựng một giá trị trao đổi lớn để

bán-giá-cho-tràn tràn ether được chuyển đổi được tính toán, và 2 10 432

"giá cao và bán thấp" được thực hiện.

Chủ sở hữu chuyển nhiều mã thông báo hơn số dư tài khoản
tràn quá nhiều mã
khi chuyển sang xây dựng một dòng chảy ngầm, nhận ra bất kỳ 5 11 517
thông báo
gia tăng trong tài khoản.

giảm cân bằng tràn Chủ sở hữu kiểm soát số dư tài khoản bằng cách thêm nhiều
5 24 1126
mã thông báo vào tài khoản để đạt được mức tràn.

Khi chủ sở hữu phân bổ mã thông báo cho tài khoản, anh ta có thể
phân bổ thừa theo
bỏ qua giới hạn trên bằng cách tràn, do đó chỉ định 1 14 341
tràn
nhiều mã thông báo hơn đến địa chỉ được chỉ định.

Chủ sở hữu tạo tràn bằng cách chuyển vào một giá trị lớn,
thừa-mint-token-by tràn
bỏ qua việc thiết lập giá trị tối đa của tiền xu trong 3 9 778

hợp đồng, để phát hành bất kỳ số lượng tiền xu.

Người dùng mua một số lượng đủ lớn các mã thông báo để tạo một
dư thừa-mua-token-by
tràn, do đó bỏ qua giới hạn trên của đồng xu 3 42 992
tràn
phát hành và nhận được nhiều mã thông báo hơn.

ví dụ về tràn Hợp đồng thông minh minh họa các lỗ hổng tràn số nguyên. 10 24 353

Tổng cộng 40 179 7451

Machine Translated by Google

Jinlei Sun và cộng sự: Thử nghiệm đột biến cho tràn số nguyên trong hợp đồng thông minh Ethereum 35

kiểm tra thủ công các lỗ hổng tràn số nguyên trong xem xét thủ công và đếm số lượng được tạo
hợp đồng và đánh dấu chúng; sau đó, chúng tôi sửa các số nguyên này đột biến với lỗ hổng tràn số nguyên.
tràn lỗ hổng để có được phiên bản sửa chữa của Thứ ba là điều tra xem liệu các dị nhân có thể
mỗi ESC. đạt được sự mô phỏng của các lập trình viên có xu hướng

5.3 Thí nghiệm 1: Hiệu quả của đột biến phạm sai lầm trong quá trình mã hóa. người đột biến

toán tử trong việc tạo đột biến gần với lỗ hổng thực sự hơn và trường hợp thử nghiệm có thể

được đánh giá thêm. Để kết thúc này, chúng tôi phân tích xem liệu
Trong thử nghiệm này, chúng tôi sử dụng tỷ lệ hợp lệ của
các đột biến được tạo bao gồm các loại số nguyên khác nhau
đột biến bởi các nhà khai thác của chúng tôi, số lượng đột biến mà
lỗ hổng tràn trong ESC. Sau đó, chúng tôi tính
chứa các lỗ hổng tràn số nguyên và số
số lỗ hổng trong ESC ban đầu có thể
các lỗ hổng ban đầu có thể được sao chép thành
được sao chép.
đánh giá hiệu quả của đột biến đề xuất
5.3.2 Kết quả của Thí nghiệm 1
người vận hành.

5.3.1 Bố trí thí nghiệm Kết quả của các đột biến được tạo ra từ 40 ESC bởi

các toán tử đột biến được đề xuất được trình bày trong Bảng 8. Trong
Mục đích của thí nghiệm này là để đánh giá
theo cách này, tất cả các thể đột biến được chọn cho thí nghiệm này
hiệu quả của các nhà khai thác của chúng tôi trong việc tạo ra các đột biến. ĐẾN

là những đột biến không tương đương.

kết thúc này, trước tiên chúng tôi kiểm tra tràn số nguyên theo cách thủ công
Như thể hiện trong Bảng 8, tổng số tràn 2099 số nguyên
lỗ hổng trong hợp đồng ban đầu và đánh dấu chúng.
Sau đó, chúng tôi sửa các lỗ hổng được phát hiện để có được đột biến được tạo cho 40 hợp đồng thông minh. Các

số lượng đột biến được tạo bởi CSC và CSD

phiên bản sửa chữa của mỗi hợp đồng thông minh. Cuối cùng chúng ta
các nhà khai thác là như nhau. Kết quả này có được vì
thay đổi hợp đồng thông minh đã sửa chữa. đánh giá này là

chủ yếu được tiến hành từ ba khía cạnh sau: Các toán tử CSC và CSD được thay đổi theo điều kiện

Đầu tiên là đếm số lượng đột biến có thể phát biểu tương ứng với phép toán số học.

biên soạn. Mã Solidity được viết bởi lập trình viên Sự khác biệt là toán tử CSC thay đổi

cuối cùng có thể được biên dịch. Nếu đột biến được tạo ra không thể câu và toán tử CSD trực tiếp xóa

vượt qua trình biên dịch Solidity, ngay cả khi nó chứa một số nguyên câu. Số lượng thể đột biến được tạo ra bởi

lỗ hổng tràn, nó không có tác dụng trong thử nghiệm đột biến. Toán tử SOR tương đối nhỏ (chỉ 89) vì

Cuối cùng, chúng tôi sử dụng trình biên dịch Solidity để có được số lượng đột biến được tạo bởi SOR cho một số ESC

số lượng đột biến có thể được biên dịch. là 0. Phân tích sâu hơn cho thấy ESC trong một số
Thứ hai là để kiểm tra số lượng đột biến mà các danh mục không sử dụng thư viện hàm SafeMath và

chứa tràn số nguyên. Mục đích của nghiên cứu này là để toán tử SOR là toán tử đột biến cho SafeMath

điều tra thử nghiệm đột biến cho tràn số nguyên trong ESC. chức năng thư viện. Số lượng thể đột biến được tạo ra bởi

Do đó, chúng ta cần các toán tử để tạo ra các đột biến VTC và SUR/USR tương đối lớn (732 và

với lỗ hổng tràn số nguyên. Nếu một dị nhân làm 676, tương ứng) vì hai toán tử đột biến này
không chứa bất kỳ lỗ hổng tràn số nguyên nào, thì nó thay đổi đối với các biến có kiểu số nguyên, thường là
được sử dụng trong ESC.
không có tác dụng trong việc đánh giá test case. Để đạt được điều này, chúng tôi

Bảng 8 Số đột biến của năm toán tử cho 10 loại ESC.

Loại CSC CSD SOR VTC SUR/USR Tổng cộng

hàng loạtTransfer-tràn 25 25 34 65 63 212

tổng cung-tràn xác 62 62 0 118 112 354

minh-không hợp lệ-do tràn- 4 4 0 54 47 109
giá-bán-cho-tràn-thừa- 25 25 0 63 58 171

mã thông báo-theo-tràn giảm- 12 12 0 53 53 130

cân bằng-theo-tràn vượt quá- 73 73 48 150 148 492
phân bổ theo tràn vượt quá- 12 12 0 26 25 75
đúc-mã thông báo-theo-tràn-mua 18 18 7 51 49 143
-token-by-overflow ví dụ về 54 54 0 126 99 333
tràn 16 16 0 26 22 80
Tổng cộng 301 301 89 732 676 2099
Machine Translated by Google
36
Đối với khía cạnh đầu tiên, chúng tôi quan sát xem người đột biến có
có thể được tuân thủ. Các đột biến có thể được biên dịch là
được gọi là Hợp lệ; nếu không, nó được gọi là Không hợp lệ. Con số
và tỷ lệ các đột biến hợp lệ và không hợp lệ được hiển thị trong
dòng 2 của bảng 9. Trong bảng 9, dòng đầu tiên là số
của các đột biến được tạo ra, dòng thứ hai là số
của các đột biến hợp lệ có thể được tuân thủ bởi Solidity
complier, và dòng thứ ba là số lượng đột biến mà
chứa lỗ hổng tràn số nguyên.
Như thể hiện trong Dòng 2 của Bảng 9, 1393 của tất cả 2099
đột biến (khoảng 66%) là Hợp lệ. Từ
quan điểm của các toán tử đột biến khác nhau, tất cả các
các đột biến được tạo bởi các toán tử CSC, CSD và SOR
là hợp lệ, với tỷ lệ 100%. Hầu hết các dị nhân
được tạo bởi VTC (695 trong 732) là Hợp lệ, với tỷ lệ
xấp xỉ 95%. Bằng cách phân tích các dị nhân không hợp lệ,
chúng tôi thấy rằng các tham số đầu vào trước SafeMath
chức năng thư viện, chẳng hạn như “.add()”, không thể biên dịch
sau đột biến. Vì hợp đồng quy định rằng
Thư viện SafeMath chỉ được sử dụng cho số nguyên kiểu uint256,
và VTC chuyển đổi số nguyên uint256 thành số nguyên uint128,
và sau đó xảy ra lỗi biên dịch khi sử dụng
Hàm SafeMath. Hầu hết các đột biến được tạo ra bởi
SUR/USR không hợp lệ. Chỉ có 7 trong số 676 dị nhân là
Có hiệu lực. Qua phân tích, chúng tôi thấy rằng SUR/USR
toán tử thay đổi kiểu của một số nguyên khi số nguyên
biến được sử dụng sau định nghĩa. Hầu hết các biến
được sử dụng để tham gia vào số học hoặc chuyển vào
chức năng như các tham số. Một mặt, khi các biến
với các ký hiệu khác nhau có mặt trong số học,
vượt qua trình biên dịch Solidity là không thể. trên
mặt khác, nếu loại đầu vào không khớp với
chức năng, sau đó mã không thể được biên dịch, dẫn đến
nhiều dị nhân không hợp lệ. Hơn nữa, chức năng đột biến
với các loại đối số đầu vào linh hoạt gây ra bảy
Mutants được biên dịch thành công. Kết quả này cũng
cho thấy rằng toán tử đột biến của tràn đã ký
đối với hợp đồng thông minh Solidity gần như không hợp lệ. Nếu chúng ta
loại bỏ các đột biến được tạo bởi toán tử SUR/USR,
chúng ta có thể kết luận rằng Tỷ lệ hợp lệ của các đột biến là 97%
(1386 năm 1423). Kết quả trên cho thấy đột biến
toán tử được đề cập trong nghiên cứu này có thể tạo ra một cách hiệu quả
Đột biến hợp lệ.
Đối với khía cạnh thứ hai, chúng tôi tính xem Hợp lệ
Bảng 9 Số đột biến có thể được tuân thủ và chứa các lỗ hổng tràn số nguyên.
Loại CSC CSĐT VTC
Đột biến 301 301
đột biến hợp lệ 301 301
Đột biến với tràn số nguyên 297 297
Khoa học và Công nghệ Thanh Hoa, tháng 2 năm 2022, 27(1): 27–
40
đột biến chứa tràn số nguyên. Số hợp lệ
đột biến có chứa lỗ hổng tràn số nguyên là
thể hiện trong Dòng 3 của Bảng 9.
Trong số 1393 người đột biến hợp lệ, 1323 (95%)
chứa các lỗ hổng tràn số nguyên. Chúng tôi đã sửa
các lỗ hổng tràn số nguyên trong bản gốc
hợp đồng; do đó, các lỗ hổng tràn số nguyên này là
được coi là được tạo ra bởi các toán tử đột biến.
Hầu hết các đột biến được tạo ra (297 trong 301) bởi CSC
và toán tử CSD chứa ít nhất một tràn số nguyên
dễ bị tổn thương. Bằng cách phân tích các đột biến không có số nguyên
lỗ hổng tràn, chúng tôi thấy rằng việc triển khai
quá trình khớp cho câu lệnh điều kiện không phải là
đủ chính xác, dẫn đến bốn đột biến mà
không thể kích hoạt tràn số nguyên. vấn đề này xảy ra
trong việc thực hiện mã chứ không phải là một đột biến
nhà điều hành. Số thể đột biến không chứa
lỗ hổng tràn số nguyên (62) lớn hơn nhiều
hơn số lượng đột biến với tràn số nguyên
lỗ hổng (27) trong các đột biến được tạo ra bởi
toán tử SOR. Hiện tượng này chủ yếu do
bởi hai lý do. Một mặt, một số Safemath
đầu vào của chức năng là hằng số. Thay đổi chức năng
đến các toán tử thông thường không thể gây tràn số nguyên
dễ bị tổn thương. Mặt khác, nếu một câu lệnh điều kiện
để ngăn tràn số nguyên cũng được chứa, sau đó
biến đổi hàm Safemath không gây ra số nguyên
lỗ hổng tràn. VTC và SUR/USR thay đổi
loại biến, điều này chắc chắn gây ra sự cắt ngắn hoặc ký tên
lỗ hổng tràn. Các phân tích trên cho thấy rằng
các toán tử đột biến được đề cập trong nghiên cứu này có thể
tạo hiệu quả các đột biến lỗi số nguyên.
Đối với khía cạnh thứ ba, chúng tôi đếm số lượng và
tỷ lệ tổn thương sinh sản.
179 lỗ hổng tràn số nguyên trong
các hợp đồng thông minh ban đầu đều được sao chép. Bằng cách phân tích
kết quả, chúng tôi thấy rằng các toán tử được đề xuất
có thể tái tạo các lỗ hổng số nguyên trong bản gốc
hợp đồng thông minh, điều này cũng cho thấy rằng đề xuất
toán tử có thể mô phỏng hiệu quả tràn số nguyên
lỗ hổng trong ESC. Ngoài ra, nhà điều hành CSC
gây ra một số lỗi logic và thay đổi bản gốc
đường dẫn thực thi của chương trình. Vì vậy, so sánh
với CSC, toán tử CSD phù hợp để tạo
SOR SUR/USR Tổng cộng
89 732 676 2099
89 695 7 1393
27 695 7 1323
Machine Translated by Google

Jinlei Sun và cộng sự: Thử nghiệm đột biến cho tràn số nguyên trong hợp đồng thông minh Ethereum 37

đột biến lỗ hổng số nguyên thuần túy. (1386 năm 1423). Trong khi đó, 95% (1323 trong 1393) của

Để tiến hành một thử nghiệm so sánh với hiện có các đột biến hợp lệ chứa các lỗ hổng tràn số nguyên,

công cụ, nghiên cứu này lựa chọn phương pháp được đề xuất bởi và 179 lỗ hổng tràn số nguyên trong

Andesta và cộng sự[35]. Phương pháp này thiết kế 10 loại ESC ban đầu đều được sao chép bởi các toán tử đột biến.
toán tử đột biến cho các loại hợp đồng thông minh khác nhau Thông qua phân tích so sánh, phương pháp đề xuất

lỗ hổng, bao gồm tràn số nguyên. chúng tôi sử dụng trong nghiên cứu này vượt trội so với các phương pháp hiện có trong

công cụ được triển khai trên cơ sở trình biến đổi phổ quát đột biến tràn số nguyên. Vì vậy, đột biến

của nghiên cứu này để thực hiện đột biến tràn số nguyên nhà điều hành đề xuất trong nghiên cứu này được coi là có thể
trên 40 ESC đã chọn. Kết quả cho thấy năm 2022 để (a) tạo cả ba kiểu tràn số nguyên

trong số tất cả 5422 đột biến có thể được tổng hợp, với tỷ lệ phần trăm các lỗ hổng một cách hiệu quả và (b) tái tạo các lỗ hổng khác nhau

là 40,6%. Qua phân tích sâu hơn, chúng tôi thấy rằng lỗ hổng tràn số nguyên trong ESC thế giới thực.

toán tử cắt xén và tràn có dấu trong công cụ này

5.4 Thí nghiệm 2: Hiệu quả của đột biến
thực hiện đột biến khi biến xuất hiện, nhưng chúng tôi
toán tử trong thử nghiệm đột biến
toán tử thực hiện đột biến khi biến được sử dụng.
Trong thí nghiệm này, chúng tôi sử dụng các đột biến được tạo ra bởi
Ngoài ra, phương pháp trong Ref. [35] không thay đổi
tuyên bố điều kiện theo tuyên bố hoạt động năm toán tử đột biến để đánh giá tràn số nguyên

nhưng trực tiếp thay đổi tất cả các điều kiện thành “True” hoặc công cụ phát hiện lỗ hổng có tên Osiris[37], hãy tìm

“Sai” và do đó không gây tràn số nguyên khuyết điểm và nâng cao hiệu quả.

thất bại nhưng là một thất bại logic. Ngoài ra, Safemath 5.4.1 Thiết lập thí nghiệm
chức năng không bị đột biến trong Ref. [35]. Do đó, các Mục đích của thí nghiệm này là để đánh giá
Phương pháp được đề xuất trong nghiên cứu này hiệu quả hơn phương pháp
hiệu quả của các đột biến trong việc đánh giá các trường hợp thử nghiệm hoặc
phương pháp của Andesta và cộng sự.[35] về tràn số nguyên
công cụ kiểm tra bằng cách tính điểm đột biến của thử nghiệm
lỗ hổng' đột biến. Ưu điểm của Ref. [35]
công cụ trong quá trình thử nghiệm.

là nó đề xuất một loạt các toán tử đột biến cho

Công cụ thử nghiệm được chọn trong thí nghiệm này là Osiris[37],
nhiều hợp đồng thông minh; đề xuất như vậy là một trong những đề xuất của chúng tôi
lỗ hổng tràn số nguyên ESC mã nguồn mở
công việc tương lai.
công cụ phát hiện dựa trên công nghệ thực thi tượng trưng
Trả lời cho RQ1: Toán tử đột biến có thể
với tỷ lệ dương tính giả thấp.
biến đổi ESC một cách hiệu quả? Toán tử đột biến
Các bước thực nghiệm như sau: Đầu tiên, chúng tôi
đề xuất trong nghiên cứu này có thể tạo ra 2099 đột biến từ
sử dụng Osiris để kiểm tra các dị nhân được tạo ra từ 40 thông minh
40 ESC, trong đó có 1393 đột biến hợp lệ có thể
hợp đồng và sau đó có được kết quả kiểm tra và đột biến
biên soạn. Trong số các dị nhân không hợp lệ, 669 là từ
điểm số. Cuối cùng, chúng tôi phân tích công cụ Osiris theo
Toán tử đột biến USR/SUR. lý do chính là
với kết quả kiểm tra.
trình biên dịch Solidity tự động kiểm tra các biến
5.4.2 Kết quả của Thí nghiệm 2
với các ký hiệu khác nhau. Nếu phần này bị loại bỏ, thì
số lượng đột biến hợp lệ chiếm 97% tổng số Kết quả được thể hiện trong Bảng 10. Chúng tôi liệt kê số

Bảng 10 Kết quả chạy Osiris trên các dị nhân. “T” đại diện cho số lượng các đột biến phù hợp, “K” đại diện cho
số dị nhân bị giết bởi Osiris, và “S” đại diện cho số dị nhân còn sống sót.
CSC CSD SOR VTC SUR/USR
Loại
TKS TKS TKSTKSSTKS
hàng loạtTransfer-tràn 25 12 13 25 16 9 18 12 6 62 1 61 0 0 0
tổng cung-tràn xác 61 27 34 61 29 32 0 0 0 112 2 110 2 0 2
minh-không hợp lệ-do tràn- 4 0 4 4 0 4 0 0 0 54 0 54 5 0 5
giá-bán-cho-tràn-thừa- 25 20 5 25 22 3 0 0 0 61 2 59 0 0 0
mã thông báo-theo-tràn giảm- 12 số 8 4 12 9 3 0 0 0 53 0 53 0 0 0
cân bằng-theo-tràn vượt quá- 73 51 22 73 52 21 3 2 1 141 2 139 0 0 0
phân bổ theo tràn vượt quá- 12 4 số 8 12 0 12 0 0 0 26 0 26 0 0 0
đúc-mã thông báo-theo-tràn-mua 18 14 4 18 16 2 6 6 0 49 1 48 0 0 0
-token-by-overflow ví dụ về 51 6 45 51 0 51 0 0 0 111 3 108 0 0 0
tràn 16 4 12 16 14 2 0 0 0 26 0 26 0 0 0
Tổng cộng 297 146 151 297 158 139 27 20 7 695 11 684 7 0 7
Machine Translated by Google

38 Khoa học và Công nghệ Thanh Hoa, tháng 2 năm 2022, 27(1): 27–40

của các đột biến được tạo ra, bị giết và sống sót bởi các nhà khai Do đó, các toán tử đột biến được đề xuất trong nghiên cứu này có

thác CSC, CSD, SOR, VTC và SUR/USR trong Bảng 10. thể được coi là hiệu quả trong việc đánh giá các công cụ kiểm tra

Điểm số đột biến sau đó được tính toán. lỗ hổng tràn số nguyên và giúp cải thiện tính đầy đủ của nó.

Để chứng minh khả năng của Osiris trong việc phát hiện lỗ hổng

tràn số nguyên một cách trực quan, chúng tôi vẽ sơ đồ điểm số đột
6 Mối đe dọa đối với giá trị
biến của Osiris giữa các đột biến khác nhau trong Hình 11.

Một mối đe dọa đối với tính hợp lệ trong đánh giá của chúng tôi có
Osiris có điểm đột biến cao nhất trong số các dị nhân do toán tử
thể là chúng tôi chủ yếu chọn các hợp đồng thông minh Mã thông báo
đột biến SOR tạo ra, đạt 74,1 (tiêu diệt 20 trong số 27 dị nhân).
ERC20 để tiến hành thử nghiệm của mình và do đó có thể mang lại tính
Các dị nhân sống sót chủ yếu có đột biến trong khối vòng lặp “for”,
phiến diện cho kết quả thử nghiệm. Để giảm bớt tình trạng này, chúng
cho thấy Osiris gặp khó khăn trong việc phát hiện các lỗ hổng tràn
tôi đã chọn 30 hợp đồng thông minh mã nguồn mở với 9 loại lỗ hổng
số nguyên như vậy. Osiris đạt điểm thấp đối với các đột biến do VTC
tràn số nguyên khác nhau. Đồng thời, một số hợp đồng thông minh,
và SUR/USR tạo ra (1,6 và 0), cho thấy rằng Osiris khó có thể phát
được sử dụng làm ví dụ cho lỗ hổng tràn số nguyên ESC, được chọn.
hiện ra phần cắt ngắn và tràn ký tự trong ESC.

Một mối đe dọa khác đối với tính hợp lệ của đánh giá của chúng
Điểm đột biến của Osiris trong các dị nhân CSC và CSD là 49,2 và
tôi có thể là trong Thử nghiệm 2, chúng tôi chỉ chọn một công cụ
53,2, tương đương với khoảng một nửa số dị nhân bị giết. Các dị nhân
kiểm tra lỗ hổng tràn số nguyên, điều này có thể không đủ để phản
CSC và CSD còn sống sót có thể được chia thành ba loại. Đầu tiên là
ánh hiệu quả của phương pháp này trong việc đánh giá các trường hợp
câu biến thể trong thể dị nhân là
kiểm tra hoặc công cụ kiểm tra khác. Chúng tôi sẽ thử nhiều công cụ

hơn trong công việc tương lai của chúng tôi.

một câu có hậu điều kiện. Thứ hai là một số phép tính số học liên

quan đến các con số. Thứ ba là kết quả của số học không được sử
7 Kết luận và công việc trong tương lai
dụng. Hai loại đầu tiên là sự thiếu sót trong khả năng phát hiện

của Osiris. Loại thứ ba, kết quả số học không được sử dụng có thể Tràn số nguyên là một trong những lỗ hổng phổ biến nhất trong ESC

bị tràn nhưng không gây hậu quả nghiêm trọng; đặc điểm như vậy là và nó gây ra nhiều thiệt hại về kinh tế. Do đó, việc tìm ra lỗ hổng

một lợi thế của Osiris. tràn số nguyên trong ESC là rất quan trọng. Kiểm thử đột biến là

một kỹ thuật để đánh giá các trường hợp kiểm thử và cải thiện mức

độ đầy đủ của kiểm thử. Nghiên cứu này áp dụng thử nghiệm đột biến

Trả lời cho RQ2: Các đột biến do người vận hành đột biến tạo ra để kiểm tra lỗ hổng tràn số nguyên trong ESC và đề xuất năm toán tử

có thể đánh giá hiệu quả các trường hợp thử nghiệm hoặc công cụ thử đột biến dành riêng cho lỗ hổng tràn số nguyên.

nghiệm không? Thông qua các đột biến được tạo bởi toán tử đột biến

được đề xuất trong nghiên cứu này, công cụ phát hiện lỗ hổng tràn Nghiên cứu thực nghiệm cho thấy rằng các toán tử đột biến trong

số nguyên Osiris được đánh giá và điểm số đột biến của Osiris trên nghiên cứu này có thể tạo ra các đột biến lỗ hổng tràn số nguyên và
CSC, CSD, SOR, VTC và SUR/USR là 49,2, 53,2, 74,1, 1,6 , và 0 tương đánh giá các công cụ kiểm tra lỗ hổng tràn số nguyên. Nói cách khác,
ứng. Bằng cách phân tích những dị nhân còn sống sót, chúng ta có thể phương pháp của chúng tôi có hiệu quả trong việc cải thiện chất

biết được những ưu điểm và nhược điểm của Osiris. lượng kiểm tra lỗ hổng tràn số nguyên trong ESC. Trong công việc

tương lai của chúng tôi, một mặt, chúng tôi sẽ nghiên cứu những

thiếu sót của toán tử đột biến trong nghiên cứu này và mở rộng ứng

dụng cho các trường hợp thử nghiệm khác và đánh giá công cụ thử

nghiệm. Mặt khác , chúng tôi sẽ mở rộng thử nghiệm đột biến sang

các loại lỗ hổng khác.

Nhìn nhận

Dự án được hỗ trợ bởi Chương trình NC&PT trọng điểm quốc gia Trung

Quốc (Số 2018YFB1403400), Quỹ khoa học tự nhiên quốc gia Trung Quốc

(Số 61702544), Quỹ khoa học tự nhiên tỉnh Giang Tô, Trung Quốc

Hình 11. Điểm đột biến của Osiris trên các toán tử khác nhau.
Machine Translated by Google
Jinlei Sun và cộng sự: Thử nghiệm đột biến cho tràn số nguyên trong hợp đồng thông minh Ethereum
(Số BK20160769 và BK20141072) và Quỹ Khoa học Sau
Tiến sĩ Trung Quốc (Số 2016M603031).
Người giới thiệu
[1] S. Nakamoto, Bitcoin: Tiền điện tử ngang hàng
hệ thống, https://bitcoin.org/en/bitcoin-paper, 2008.
[2] G. Wood, Ethereum: Sổ cái giao dịch tổng quát phi tập trung an toàn,
http://gavwood.com/Paper.pdf, 2014.
[3] Solidity, https://solidity.readthedocs.io/en/develop/, 2020.
[4] I. Nikolic A. Kolluri, I. Sergey, P. Saxena và A. Hobor, Tìm kiếm
các hợp đồng tham lam, hoang đàng và tự sát trên quy mô lớn, bản
in lại arXiv arXiv: 1802.06038v2, 2018.
[5] D. Siegel, Hiểu về cuộc tấn công DAO, https://www.coindesk.com/under
Hiểu -dao-hackjournalists, 2016.
[6] Công nghệ chẵn lẻ, Phân tích hậu kỳ về tính năng tự hủy của thư
viện multi-sig chẵn lẻ, https://www.parity.io/a-postmortemon the-
parity-multi-sig-library-self-destroy/, 2017.
[7] B. Chuỗi, mã nguồn hợp đồng mã thông báo BEC, https://etherscan.io/
address/0xc5d105e63711398af9bbff092d4b6769
c82f793d#hợp đồng, 2018.
[8] S. Kalra, S. Goel, M. Dhawan, và S. Sharma, ZEUS: Phân tích tính an
toàn của hợp đồng thông minh, trong Network and Distributed System
Security Symp., San Diego, CA, USA, doi: 10.14722/ndss . 2018.23092.
[9] H. Wu, X. Wang, J. Xu, W. Zou, L. Zhang và Z. Chen, Thử nghiệm đột
biến cho hợp đồng thông minh ethereum, bản in trước arXiv arXiv :
1908.03707, 2019.
[10] GitHub, https://github.com/SmartcontractTest, 2020.
[11] N. Szabo, Hợp đồng thông minh: Khối xây dựng cho thị trường kỹ
thuật số, https://kameir.com/smart-contracts/, 1996.
[12] Y. Jia và M. Harman, Một phân tích và khảo sát về sự phát triển
của thử nghiệm đột biến, IEEE Trans. Phần mềm Eng., vol. 37,
không. 5, trang 649–
678, 2011.
[13] RA DeMillo, RJ Lipton và FG Sayward, Gợi ý về lựa chọn dữ liệu thử
nghiệm: Trợ giúp cho lập trình viên thực hành, Máy tính, tập. 11,
không. 4, trang 34–
41, 1978.
[14] AJ Offutt, Điều tra về hiệu ứng liên kết thử nghiệm phần mềm, ACM
Trans. Phần mềm Eng. Phương pháp., tập. 1, không. 1, trang 3–
18,
1992.
[15] R. Ma, S. Ren, K. Ma, C. Hu và J. Xue, Tạo trường hợp thử nghiệm
fuzz bán hợp lệ cho giao thức mạng có trạng thái, Khoa học và Công
nghệ Thanh Hoa, tập. 22, không. 5, trang 458–
468 , 2017.
[16] LM Zhang, T. Xie, L. Zhang, N. Tillmann, J. De Halleux và H. Mei,
Tạo thử nghiệm thông qua thực thi ký hiệu động để thử nghiệm đột
biến, trong Proc. 2010 IEEE Int. Conf. Bảo trì phần mềm ,
Timisoara, Romania, 2010.
[17] MC S·nchez, JMC de Gea, JL Fern·ndez-Alem·n, J. Garceran và AT
S·nchez. Tổng quan về lỗ hổng phần mềm: Một nghiên cứu mô tả,
Khoa học và Công nghệ Thanh Hoa, tập. 25, không. 2, trang 270–
280, 2020.
[18] WE Wong và AP Mathur, Giảm chi phí thử nghiệm đột biến: Một nghiên
cứu thực nghiệm, J . hệ thống. Softw., vol. 31, không. 3, trang
185–
196, 1995.
[19] PG Frankl, SN Weiss, và C. Hu, Thử nghiệm mọi công dụng và đột
biến : So sánh thử nghiệm về hiệu quả, J. Syst. Softw., vol. 38,
không. 3, trang 235–253, 1997.
39
[20] M. Polo, M. Piattini, và I. Garc´ıa-Rodr´ıguez, Giảm chi phí thử
nghiệm đột biến với các thể đột biến bậc hai, Softw. Bài kiểm
tra. xác minh. Đáng tin cậy, tập. 19, không. 2, trang 111–
131, 2009.
[21] H. Coles, T. Laurent, C. Henard, M. Papadakis và A.
Ventresque, PIT: Một công cụ kiểm tra đột biến thực tế cho Java,
¨
trong Proc. Quốc tế thứ 25 Symp, Saarbrücken, Đức, 2016.
[22] A. Derezinska và A. Szustek, Khả năng kiểm tra hướng đối tượng và
đánh giá hiệu suất của hệ thống đột biến C#, trong Proc. IFIP TC
2 lần thứ 4 Trung và Đông Âu Conf. Kỹ thuật Công nghệ Phần mềm,
Krakow, Ba Lan, 2012, trang 229–242.
´
[23] P. Delgado-Perez, I. Medina-Bulo, F. Palomo-Lozano, A. Garc´ıa-Dom
´ınguez, và JJ Dom´ınguez-Jimenez, ´ Đánh giá toán tử đột biến
lớp cho C++ bằng MuCPP hệ thống đột biến, Inf. mềmw. Công nghệ,
tập. 81, trang 169–
184, 2017.
[24] YS Ma, MJ Harrold, và YR Kwon, Đánh giá thử nghiệm đột biến cho
các chương trình hướng đối tượng, được trình bày tại 28th Int.
Conf. Kỹ thuật phần mềm, Thượng Hải, Trung Quốc,
2006.
[25] SW Kim, JA Clark và JA Mcdermid, Đánh giá mức độ thỏa đáng của bộ
kiểm tra cho các chương trình hướng đối tượng bằng cách sử dụng
biến đổi lớp, được trình bày tại Symp. Lớp đột biến, York, Anh,
2016.
[26] SW Kim, JA Clark và JA Mcdermid, Đột biến lớp: thử nghiệm đột biến
cho các chương trình hướng đối tượng, trong Proc. Conf.
Hệ thống phần mềm hướng đối tượng, Erfurt, Đức, 2000.
[27] K. Claessen và J. Hughes, QuickCheck: Một công cụ nhẹ để kiểm tra
ngẫu nhiên các chương trình Haskell, ACM SIGPLAN Not., tập. 46,
không. 4, trang 268–
279, 2000.
[28] D. Le, MA Alipour, R. Gopinath và A. Groce, MuCheck: Một công cụ
có thể mở rộng để kiểm tra đột biến của các chương trình haskell,
trong Proc. 2014 quốc tế Triệu chứng Kiểm thử và Phân tích Phần
mềm, San Jose, CA, USA, 2014.
[29] L. Deng, N. Mirzaei, P. Ammann và J. Offutt, Hướng tới phân tích
đột biến của các ứng dụng Android, trong Proc. Quốc tế thứ 8 Conf.
Hội thảo xác minh và xác nhận kiểm thử phần mềm (ICSTW), Graz,
Áo, 2015.
´
[30] K. Moran, M. Tufano, C. Bernal-Cardenas, M. Linares- Vasquez, G.
´
Bavota, C. Vendome, MD Penta và D.
Poshyvanyk, MDroid+: Khung thử nghiệm đột biến dành cho
Android, trong Proc. 2018 IEEE/ACM lần thứ 40 Conf. Công
nghệ phần mềm : Đồng hành (ICSE-Companion), Gothenburg,
Thụy Điển, 2018.
[31] S. Mirshokraie, A. Mesbah, và K. Pattabiraman, Thử nghiệm đột biến
có hướng dẫn cho các ứng dụng web JavaScript, IEEE Trans. mềmw.
Anh, tập. 41, không. 5, trang 429–444, 2015.
[32] J. Chen, H. Wang, D. Towey, C. Mao, R. Huang và Y. Zhan, Cách tiếp
cận đột biến đầu vào tồi tệ nhất để kiểm tra lỗ hổng dịch vụ web
dựa trên thông báo SOAP, Khoa học và Công nghệ Thanh Hoa, tập.
19, không. 5, trang 429–441, 2014.
[33] ZX Li, HR Wu, JH Xu, XY Wang, LM Zhang và ZY Chen, MuSC:
Một công cụ để thử nghiệm đột biến của hợp đồng thông
minh ethereum, trong Proc. Lần thứ 34 IEEE/ACM Int. Conf.
Kỹ thuật phần mềm tự động (ASE), San Diego, CA, USA, 2019.
[34] P. Hartel và R. Schumi, Thử nghiệm đột biến của hợp đồng thông minh
theo tỷ lệ, arXiv in sẵn arXiv: 1909.12563, 2019.
Machine Translated by Google
40
[35] E. Andesta, F. Faghih và M. Fooladgar, Thử nghiệm các hợp đồng
thông minh trở nên thông minh hơn, arXiv bản in trước arXiv:
1912.04780, 2019.
[36] L. Luu, DH Chu, H. Olickel, P. Saxena, và A. Hobor, Làm
cho hợp đồng thông minh trở nên thông minh hơn, trong
Proc. Hội nghị ACM SIGSAC 2016 An ninh máy tính và truyền
thông, Viên, Áo, 2016.
¨
[37] CF Torres, J. Schutte, và R. State, Osiris: Săn lùng lỗi số
nguyên trong hợp đồng thông minh ethereum, trong Proc. 34th Ann.
Ứng dụng bảo mật máy tính Conf. (ACSAC), San Juan, PR, Hoa Kỳ,
2018.
´
[38] K. Bhargavan, N. Swamy, S. Zanella-Beguelin và A. Delignat-
Lavaud, Xác minh chính thức hợp đồng thông minh: Bài viết
ngắn, trong Proc. 34th Ann. Ứng dụng bảo mật máy tính
Conf. (ACSAC'18), San Juan, PR, Hoa Kỳ, 2016.
[39] Y. Hirai, Xác minh chính thức hợp đồng Chứng thư trong dịch vụ tên
Ethereum, https://yoichihirai.com/deed.pdf, 2016.
[40] P. Tsankov, A. Dan, D. D. Cohen, A. Gervais, F. Buenzli và M.
Vechev, Securify: Phân tích bảo mật thực tế của các hợp đồng thông
minh , bản in trước của arXiv arXiv: 1806.01143, 2018.
[41] S. Tikhomirov, E. Voskresenskaya, I. Ivanitskiy, R.
Takhaviev, E. Marchenko và Y. Alexandrov, SmartCheck: Phân
tích tĩnh các hợp đồng thông minh ethereum, trong Proc.
2018 IEEE/ACM 1st Int. Hội thảo về Xu hướng mới nổi trong
Kỹ thuật phần mềm cho Chuỗi khối (WETSEB), Gothenburg,
Thụy Điển, 2018.
Jinlei Sun nhận bằng Cử nhân toán học và
toán học ứng dụng của Đại học Nam Xương
năm 2016 và bằng Thạc sĩ Kỹ thuật phần mềm
của Đại học Kỹ thuật Quân đội PLA năm 2018.
Anh ấy hiện đang theo học bằng Tiến sĩ về kỹ
thuật phần mềm tại Đại học Kỹ thuật Quân đội
PLA. Mối quan tâm nghiên cứu của ông là trong
lĩnh vực thử nghiệm biến chất, thử nghiệm GUI và thử nghiệm đột biến.
Changyou Zheng đã nhận bằng tiến sĩ về thông
tin quân sự tại Đại học Khoa học và Công nghệ
PLA vào năm 2013. Anh ấy hiện là giáo viên tại
Đại học Kỹ thuật Quân đội của PLA. Mối quan tâm
nghiên cứu của ông là trong lĩnh vực kiểm thử
phần mềm và chuỗi khối.
Song Huang nhận bằng Tiến sĩ tại Đại học
Khoa học và Công nghệ PLA năm 2002. Ông là
thành viên của CCF
và ACM. Ông hiện là giáo sư kỹ thuật phần
mềm tại Trung tâm Kiểm tra và Đánh giá
Phần mềm, Đại học Kỹ thuật Quân đội PLA.
Anh ấy là thành viên của ban cố vấn của
Tạp chí Hệ thống và Phần mềm, Giao dịch
của IEEE về Độ tin cậy, v.v. Lĩnh vực nghiên cứu hiện tại của
anh ấy là trong lĩnh vực kiểm thử phần mềm, đảm bảo chất lượng,
khai thác dữ liệu và kỹ thuật phần mềm theo kinh nghiệm.
Khoa học và Công nghệ Thanh Hoa, tháng 2 năm 2022, 27(1): 27–
40
[42] PC Zhang, F. Xiao và XP Luo, SolidityCheck: Nhanh chóng phát hiện
các vấn đề về hợp đồng thông minh thông qua các biểu thức chính
quy, arXiv preprint arXiv: 1911.09425v1, 2019.
[43] J. Feist, G. Grieco và A. Groce, Slither: Khung phân tích
tĩnh cho hợp đồng thông minh, trong Proc. 2019 IEEE/ACM
lần thứ 2 Hội thảo về Xu hướng mới nổi trong Kỹ thuật phần
mềm cho chuỗi khối (WETSEB), Montreal, Canada, 2019.
[44] T. Durieux, JF Ferreira, R. Abreu và P. Cruz, Đánh giá thực nghiệm
các công cụ phân tích tự động trên 47587 Hợp đồng thông minh
Ethereum, bản in trước arXiv arXiv: 1910.10601, 2019.
[45] B. Jiang, Y. Liu và WK Chan, ContractFuzzer: Fuzzing hợp
đồng thông minh để phát hiện lỗ hổng, được trình bày tại
IEEE/ACM Int lần thứ 33 năm 2018. Conf. Kỹ thuật phần mềm
tự động (ASE), Montpellier, Pháp, 2018.
[46] HJ Wang, Y. Li, SW Lin, C. Artho, L. Ma, và Y.
Liu, thế hệ khai thác động được Oracle hỗ trợ cho các hợp đồng
thông minh, bản in trước arXiv arXiv: 1909.06605, 2019.
[47] C. Liu, H. Liu, Z. Cao, Z. Chen, BD Chen và B. Roscoe,
ReGuard: Tìm lỗi tái đăng ký trong hợp đồng thông minh,
trong Proc. ACM/IEEE lần thứ 40 Conf. Kỹ thuật phần mềm,
Gothenburg, Thụy Điển, 2018, trang 65–68.
[48] CVE-2018-10299, https://nvd.nist.gov/vuln/detail/CVE 2018-10299,
2018.
[49] sec-bit, https://github.com/sec-bit/awesome-buggy-erc20-
mã thông báo, 2018.
Tingyong Wang đã nhận bằng cử nhân vào năm 2019.
Anh ấy hiện đang theo học thạc sĩ tại Đại học
Kỹ thuật Quân đội PLA. Mối quan tâm nghiên cứu
của anh ấy là trong lĩnh vực xử lý ngôn ngữ tự
nhiên, tạo trường hợp thử nghiệm và học máy.
Cheng Zong nhận bằng Cử nhân kỹ thuật điện
và bằng Thạc sĩ Kỹ thuật điều khiển tại
Đại học Đông Nam, Nam Kinh, Trung Quốc,
lần lượt vào năm 2008 và 2014. Anh ấy hiện
đang theo học bằng Tiến sĩ về kỹ thuật
phần mềm tại Đại học Kỹ thuật Quân đội
PLA. Anh hiện đang làm việc tại Tập đoàn
Điện hạt nhân Giang Tô. Nghiên cứu sở
thích của ông là trong lĩnh vực khai thác dữ liệu, kiểm soát
công nghiệp và phân tích lỗi.
Zhanwei Hui nhận bằng tiến sĩ tại Đại học Khoa
học và Công nghệ PLA vào năm 2015. Ông hiện đang
làm việc tại Viện Nghiên cứu Đánh giá và Đánh
giá, Học viện Khoa học Quân sự. Nghiên cứu sở
thích của ông là trong lĩnh vực thử nghiệm biến
chất.