Phương pháp tiếp cận lý thuyết trò chơi cho các hợp

đồng thông minh lớn an toàn và hiệu quả

Tóm tắt - Hợp đồng thông minh trong các hệ thống chuỗi khối như Ethereum thường được
thực thi hoặc xác minh bởi tất cả các nút và do đó không hiệu quả đối với tính toán phức tạp. Bài
viết này giải quyết hạn chế bằng cách đề xuất, thực hiện và đánh giá một giải pháp thực tế và
hiệu quả dựa trên cách tiếp cận lý thuyết trò chơi. Giải pháp xác định một mẫu hợp đồng thông
minh lớn (HDSC); chỉ tuyển dụng một số ít người thực thi để thực hiện các nhiệm vụ lớn; sử
dụng một sơ đồ lý thuyết trò chơi để buộc những người thực thi hợp lý về mặt kinh tế phải thực
hiện một cách cá nhân hoặc tập thể việc thực thi một cách chính xác. Phân tích lý thuyết trò chơi
mở rộng đã được tiến hành để chỉ ra tính bảo mật và hiệu quả tính toán của giải pháp ngay cả khi
đối mặt với sự thông đồng giữa những người thực thi. Như một bằng chứng về khái niệm, giải
pháp được đề xuất đã được triển khai và thử nghiệm để chứng minh tính thực tế và khả năng
tương thích của nó với Ethereum.

Thuật ngữ chỉ mục - Blockchain, Hợp đồng thông minh, Tính toán hiệu quả, Lý thuyết trò
chơi, Thông đồng

I. Giới thiệu
Bắt đầu từ Bitcoin [1] đến Ethereum [2], chức năng của chuỗi khối được hoàn thiện từ tiền
điện tử thuần túy đến các hợp đồng thông minh cho phép tính toán cho mục đích chung theo cách
có thể kiểm chứng, minh bạch và không thể chối bỏ. Tuy nhiên, trong hầu hết các hệ thống chuỗi
khối phổ biến hiện nay, các hợp đồng thông minh phải được thực thi hoặc xác minh bởi tất cả
các nút, dẫn đến lãng phí đáng kể tính toán và khả năng mở rộng hạn chế, do đó làm cho các hợp
đồng thông minh phù hợp hơn cho tính toán đơn giản chứ không phải các tính toán phức tạp.

Các công việc liên quan & Hạn chế: Các nghiên cứu về cải thiện hiệu quả tính toán của chuỗi
khối được mở rộng. Cơ chế bằng chứng cổ phần (PoS) [3], [4], [5] - chọn các nút làm trình tạo
khối dựa trên lựa chọn ngẫu nhiên, sự giàu có, độ tuổi hoặc sự kết hợp của những điều này, đã
được khám phá như một giải pháp thay thế cho bằng chứng công việc (PoW) - chọn những người
đề xuất khối dựa trên các cuộc thi tiêu tốn năng lượng trong việc giải các câu đố mật mã. Tuy
nhiên, một hệ thống dựa trên PoS vẫn yêu cầu mọi bên liên quan tham gia xác minh (thường có
nghĩa là lặp lại) mỗi lần thực thi. Có đề xuất sử dụng môi trường thực thi tin cậy (TEE) [6], [7],
[8] để đạt được tính toán cộng đồng thay vì có tất cả các nút tham gia. Tuy nhiên, TEE phổ biến
hiện nay như Intel SGX không phù hợp với đa luồng và các tác vụ đòi hỏi nhu cầu cao về bộ
nhớ, điều này có thể khiến nó trở thành thách thức cho quá trình tính toán và xác thực khổng lồ
trên chuỗi khối. Cách tiếp cận dựa trên sharding [9], [10], [11] đã được đề xuất để chia một chuỗi
khối thành nhiều chuỗi con để có khả năng mở rộng; tuy nhiên, mỗi chuỗi con vẫn cần một số
lượng lớn thành viên để đảm bảo tính bảo mật và do đó, mỗi hợp đồng thông minh vẫn được
thực hiện lặp lại bởi một số lượng lớn các nút. Các nhà nghiên cứu cũng đề xuất cách tiếp cận
theo cấp bậc, ví dụ như Thunderella [12], trong đó định kỳ một nhà lãnh đạo và một ủy ban được
bầu để thực hiện và xác minh các giao dịch (bao gồm cả hợp đồng thông minh) và tất cả các nút
trên chuỗi chỉ được sử dụng khi tìm thấy nhà lãnh đạo không tin cậy; cách tiếp cận như vậy có
thể không cải thiện khả năng mở rộng cho các hệ thống có nhiệm vụ lớn nề vì chỉ có một số
lượng nhỏ các nhà lãnh đạo tại một thời điểm để thực hiện chúng.

Gần đây, phương pháp kết hợp on-chain/off-chain [13], [14], [15], [16], [17], [18] đã được đề
xuất, kết hợp việc thực hiện off-chain của nhiệm vụ lớn hoặc các nhiệm vụ riêng tư với việc thực
thi trực tuyến các nhiệm vụ nhẹ và không nhạy cảm với quyền riêng tư. Tuy nhiên, các thiết kế
tiên tiến nhất có một số hạn chế, chẳng hạn như khó đáp ứng các yêu cầu đặt ra cho người dùng,
không xem xét đến sự thông đồng và sử dụng các hoạt động trên chuỗi không hiệu quả, có thể
cản trở ứng dụng của chúng trong thực tế. Ví dụ: các thiết kế được đề xuất trong [14], [15], [16],
[17] đều giả định không có sự thông đồng giữa các bên liên quan và yêu cầu người dùng tìm
người thực thi ngoài chuỗi; một số thiết kế yêu cầu người thực thi ngoài chuỗi bao gồm ít nhất
một người trung thực [16] hoặc được định cấu hình bằng TEE [18] hoặc thậm chí là TTP (bên
thứ ba tin cậy) [15]; một số thiết kế yêu cầu người thực thi ngoài chuỗi chạy các giao thức tính
toán an toàn của nhiều bên [17]. Người dùng blockchain trung bình có thể thấy các yêu cầu như
vậy là bất tiện hoặc không khả thi. Một số thiết kế [16] giới thiệu nhiều vòng hoạt động thử
thách-phản hồi trên chuỗi để xác minh kết quả tính toán, điều này có thể gây ra chi phí cao cho
cả các nút trên chuỗi và người thực thi ngoài chuỗi.

Đóng góp của chúng tôi: Cách tiếp cận kết hợp hứa hẹn cải thiện hiệu quả xử lý tính toán
phức tạp trong chuỗi khối, nhưng vẫn không thực tế hoặc không hiệu quả do những hạn chế đã
thảo luận ở trên. Bài viết này nhằm mục đích giải quyết vấn đề này bằng cách đề xuất, thực hiện
và đánh giá một giải pháp thực tế và hiệu quả dựa trên cách tiếp cận.

Trong giải pháp được đề xuất, người dùng có nhiệm vụ lớn chỉ cần đăng lên blockchain một
hợp đồng thông minh lớn (HDSC) tuân theo mẫu được thiết kế của chúng tôi, trong đó số lượng
người thực thi mong muốn và các tham số tùy chọn khác được chỉ định; sau đó, người dùng gửi
tiền nên được trả cho những người thực thi trung thực. Khi HDSC đã sẵn sàng để thực thi, những
người thực thi được chọn từ các nút chuỗi khối theo quy tắc mặc định hoặc do người dùng chọn,
gửi tiền để chịu trách nhiệm cho việc thực thi của họ, thực hiện riêng lẻ hoặc tập thể nhiệm vụ
tính toán được nhúng trong HDSC, cam kết kết quả thực hiện, tiết lộ kết quả và cuối cùng nhận
được phần thưởng (nếu thực hiện tính toán một cách trung thực) hoặc mất tiền cọc (nếu không).
Với tần suất thấp và có thể thích ứng, một cơ chế tin cậy (ví dụ: chuỗi khối cơ bản, TEE có sẵn
hoặc cơ chế khác do người dùng tùy chọn chọn) cũng thực thi HDSC, đóng vai trò ngăn chặn
hành vi sai trái của người thực thi. Một sơ đồ lý thuyết trò chơi được thiết kế để điều chỉnh các
hoạt động trên sao cho những người thực thi hợp lý về mặt kinh tế phải hành động một cách
trung thực hoặc chỉ thông đồng một cách lành tính để có thể tiết kiệm chi phí tính toán nhưng kết
quả tính toán được đảm bảo chính xác.

So với các công việc liên quan đã thảo luận ở trên, giải pháp được đề xuất có các tính năng sau:
(i) Khả năng tương thích - Người dùng có thể khởi chạy HDSC theo cách gần giống như khởi
chạy hợp đồng thông minh thông thường. Họ không bắt buộc phải tìm người thực thi; nếu họ tự
chọn người thực thi, thì không có kỳ vọng gì vào những người thực thi tin cậy. Giải pháp được
đề xuất có thể chạy trên một hệ thống chuỗi khối chung, mặc dù Ethereum được giả định xuyên
suốt bài báo. (ii) Bảo mật - Như đã được chứng minh thông qua phân tích lý thuyết trò chơi, giải
pháp được đề xuất buộc những người thực thi hợp lý về mặt kinh tế phải tiến hành tính toán một
cách trung thực và gửi kết quả chính xác, bất kể họ có thông đồng hay không. (iii) Tính hiệu
quả - Việc tính toán hầu hết được thực hiện bởi những người thực thi được chọn; cơ chế tính
toán tin cậy đắt tiền hơn chẳng hạn như chuỗi khối cơ bản hoặc TEE có sẵn chỉ được sử dụng
c
làm biện pháp ngăn chặn với tần suất thấp, trong đó c là chi phí để thực hiện tính toán
n . d executor
HDSC, n là số lượng người thực thi và d executor là tiền cọc của từng người thực thi; do đó, càng
nhiều người thực thi được chọn, tần suất sử dụng cơ chế tính toán tin cậy càng thấp. Hơn nữa,
giải pháp được đề xuất khuyến khích sự thông đồng lành tính trong đó những người thực thi
thông đồng bằng cách chỉ có một trong số họ thực hiện tính toán một cách trung thực, điều này
có thể làm giảm thêm chi phí tính toán. (iv) Tính linh hoạt - Giải pháp được đề xuất chịu được
các động lực trong chuỗi khối, chẳng hạn như sự xáo trộn và sai sót của người thực thi. Ngoài ra,
người dùng được tự do xác định các thông số hoạt động cho từng HDSC.

Trình bày: Sau đây, Phần II trình bày sơ bộ. Phần III cung cấp một cái nhìn tổng quan về giải
pháp đề xuất của chúng tôi. Phần IV trình bày và phân tích các sơ đồ lý thuyết trò chơi được đề
xuất của chúng tôi. Phần V báo cáo việc triển khai lược đồ đề xuất và thảo luận về kết quả đánh
giá. Cuối cùng, Phần VI kết thúc bài báo.

II. Sơ bộ
Mô hình hệ thống: Chúng tôi xem xét một hệ thống chuỗi khối hỗ trợ tính toán cho mục đích
chung có thể kiểm chứng, minh bạch và không thể từ chối được gửi dưới dạng hợp đồng thông
minh. Chúng tôi phân loại hợp đồng thông minh thành hợp đồng thông minh lớn (HDSC) và hợp
đồng thông minh thông thường. Một HDSC yêu cầu tính toán phức tạp, và do đó, lý tưởng nhất
là chỉ được thực thi bởi một tập hợp con nhỏ (thay vì tất cả) các nút trong hệ thống. Hợp đồng
thông minh là lớn hay thông thường có thể được xác định bởi một quy tắc nhất định. Ví dụ: giới
hạn trên gas của một khối trong Ethereum có thể được đặt thành x; do đó, một hợp đồng thông
x
minh có thể tiêu thụ nhiều hơn gas có thể được phân loại là lớn nếu một khối dự kiến sẽ lưu
y
trữ nhiều hơn y giao dịch. Chúng tôi cũng giả sử việc tính toán trong mỗi HDSC là xác định; do
đó, kết quả tính toán sẽ giống nhau nếu nó được thực hiện một cách trung thực bởi các bên khác
nhau.

Giả định bảo mật: Chúng tôi cho rằng bản thân hệ thống chuỗi khối là an toàn và có các tính
năng cụ thể sau: (i) Các nút thêm khối vào chuỗi khối được chọn ngẫu nhiên. Đặc biệt, trong một
hệ thống dựa trên bằng chứng công việc, xác suất để một nút được chọn tỷ lệ thuận với phần
trăm sức mạnh tính toán mà nút đó sở hữu; trong một hệ thống dựa trên bằng chứng cổ phần, xác
suất tỷ lệ thuận với tỷ lệ phần trăm cổ phần mà nó nắm giữ. (ii) Tồn tại một giới hạn α sao cho,
một khối đã được xác nhận bởi các khối α tuyến tính theo sau nó là ổn định (hoặc không thể đảo
ngược với xác suất áp đảo).
 Chúng tôi giả định sự tồn tại của một cơ chế tính toán tin cậy. Về cơ bản, việc đăng một tác vụ
tính toán dưới dạng hợp đồng thông minh thông thường và kêu gọi tất cả các nút thực hiện hoặc
xác minh kết quả có thể phục vụ mục đích này. Để đạt hiệu quả, cơ chế tính toán tin cậy chỉ bao
gồm một tập hợp con các nút (ví dụ: thông qua phương pháp phân cấp hoặc dựa trên sharding)
hoặc một số nút đặc biệt (ví dụ: các nút được trang bị phần cứng tính toán tin cậy).

Chúng tôi giả định rằng mỗi nút trong hệ thống đều hợp lý về mặt tài chính và nhằm mục đích
tối đa hóa lợi nhuận của chính nó.

Ngoài ra, chúng tôi cho rằng một nút hoạt động sai được chọn để thực thi HDSC có thể thông
đồng với các nút khác và có thể cố gắng: (i) tự do thông qua việc chia sẻ kết quả thực thi của nút
khác mà không thực sự tiến hành thực thi theo yêu cầu; (ii) tạo ra một kết quả mà không thực
hiện thực tế; (iii) buộc tội người thực thi công vụ khác vô tội để nhận phần thưởng không xứng
đáng.

Mục tiêu thiết kế: Chúng tôi mong muốn thiết kế một giải pháp đáp ứng các mục tiêu sau: (i)
Bảo mật - Mỗi HDSC phải được thực thi chính xác. Đặc biệt, nếu một kết quả không chính xác
được đưa ra bởi một người thực thi, nó có thể được phát hiện và sửa chữa. (ii) Hiệu quả - Việc
thực hiện mỗi HDSC nên liên quan đến càng ít nút càng tốt và phát sinh chi phí thấp nhất có thể.
Mặc dù mong muốn có độ trễ thấp, nhưng chúng tôi giả sử việc tính toán trong mỗi HDSC
không nhạy cảm với độ trễ. (iii) Tính linh hoạt - Giải pháp phải thích ứng với động lực của hệ
thống, bao gồm cả lỗi và sự xáo trộn của các nút. (iv) Khả năng tương thích - Giải pháp có thể
chạy trên một hệ thống chuỗi khối chung, ví dụ: Ethereum.

III. Tổng quan về giải pháp

Trong giải pháp được đề xuất của chúng tôi, một hợp đồng thông minh lớn (HDSC) được xử lý
theo khuôn khổ sau. Đăng một hợp đồng thông minh mới: Giống như một hợp đồng thông minh
thông thường, một HDSC phải được đăng lên chuỗi khối trước khi thực thi. Chủ sở hữu HDSC
phát một giao dịch có chứa HDSC và đợi nó được đăng và ổn định. Sau khi đăng ổn định, chủ sở
hữu nộp tiền vào tài khoản của HDSC, sau này dùng để trả cho người thực thi. Để tạo thuận lợi
cho việc xử lý, một HDSC chứa các nội dung sau:
● Cờ cho biết hợp đồng thông minh này là HDSC.

● Các tham số hệ thống của HDSC này, bao gồm: n - số lượng người thực thi mong muốn;

thời hạn tối đa để thực hiện và cam kết kết quả thực hiện; thời hạn tối đa để công khai kết
quả thực hiện kể từ khi đăng tải cam kết; w - tiền lương trả cho mỗi người thực thi cung
cấp kết quả chính xác; d executor - khoản tiền cọc nên được tạo ra bởi mỗi người thực thi;
tùy chọn danh sách người thực thi do chủ sở hữu HDSC chọn.

● Mã cho tác vụ tính toán sẽ được thực thi.

● Tình trạng hiện tại của HDSC, thuộc một trong các tình trạng sau: Ban đầu, khi HDSC

được đăng nhưng người sở hữu chưa đặt cọc; Chưa sẵn sàng, khi chủ sở hữu đã đặt cọc
nhưng HDSC đang chờ các đầu vào cần thiết để thực hiện; Sẵn sàng, khi HDSC đã thu
thập các đầu vào cần thiết; Cam kết kết quả, khi người thực thi mong muốn đã đăng cam
kết của họ về kết quả hoặc thời hạn tối đa để thực hiện và cam kết đã hết; Công bố kết
quả, khi người thực thi đã công khai kết quả hoặc đã hết thời hạn tối đa để công khai;
Hoàn thành, khi HDSC đã được xử lý xong.

● Các hàm được gọi để xử lý HDSC: Đặt cọc của chủ sở hữu, được gọi bởi chính chủ sở

hữu để thực hiện đặt cọc; Cung cấp đầu vào, được gọi bởi người dùng để cung cấp đầu
vào; Kết quả cam kết, được gọi bởi một người thực thi để cam kết kết quả thực hiện của
nó và đồng thời ký gửi để chịu trách nhiệm thực hiện; Công bố kết quả, được gọi bởi một
người thực thi để tiết lộ kết quả thực hiện của nó; Báo cáo thông đồng, được gọi bởi
người dùng để báo cáo thông đồng và đồng thời gửi tiền để chịu trách nhiệm về việc báo
cáo; Giải quyết tranh chấp, được gọi để khởi chạy một lệnh thực thi tin cậy nếu có báo
cáo thông đồng hoặc sự khác biệt trong kết quả được tiết lộ; Quỹ phân phối, được gọi sau
khi kết quả tính toán của người thực thi và/hoặc quá trình thực thi tin cậy đã khởi chạy đã
hoàn thành, để phân phối tiền cọc cho các bên liên quan (chủ sở hữu, người thực thi và
người báo cáo thông đồng). Lưu ý rằng, ngoài chức năng cung cấp đầu vào dành riêng
cho tính toán, phần còn lại của các chức năng trên là chung và độc lập với tính toán được
nhúng trong HDSC.
 Cung cấp đầu vào: Đối với HDSC yêu cầu một hoặc nhiều đầu vào, người dùng nên gọi hàm
cung cấp đầu vào để cung cấp đầu vào. Khi một số lượng đầu vào cần thiết đã được cung cấp
hoặc một khoảng thời gian nhất định được chỉ định trước để cung cấp đầu vào đã hết, HDSC sẽ
chuyển sang trạng thái sẵn sàng.

Thực thi một HDSC sẵn sàng và cam kết kết quả: Đối với một HDSC chuyển sang trạng
thái sẵn sàng tại khối b0, những người thực thi nó nên bắt đầu thực thi mã tính toán được nhúng;
theo mặc định, những người thực thi nó là những thợ đào coin của khối b 0+1 , ⋯ ,b 0+ n. Sau khi
một người thực thi đã thực thi mã, nó không tiết lộ kết quả ngay lập tức để ngăn những người
thực thi khác sao chép kết quả. Thay vào đó, người thực thi gọi hàm cam kết kết quả để đăng một
cam kết mã hóa, ví dụ: cam kết nổi tiếng của Pedersen [19], về kết quả. Với chức năng này,
người thực thi cũng đặt cọc để chịu trách nhiệm về kết quả.

Tiết lộ kết quả: Sau khi tất cả những người thực thi đã đăng các cam kết hoặc khoảng thời
gian xác định cho tính toán và cam kết đã hết, mỗi người trong số những người thực thi đã cam
kết nên gọi hàm tiết lộ kết quả để mở cam kết của mình và do đó tiết lộ kết quả tính toán. Lưu ý
rằng số lượng người thực thi mong muốn và số người thực thi thực tế cuối cùng tiết lộ kết quả
của họ có thể khác nhau.

Báo cáo thông đồng: Người thực thi có thể thông đồng để tiết kiệm chi phí tính toán. Trong hệ
thống được đề xuất, người thực thi hoặc những người dùng khác được khuyến khích báo cáo
hành vi thông đồng. Trong khoảng thời gian dành cho cam kết và tiết lộ kết quả, người báo cáo
thông đồng có thể gọi chức năng báo cáo thông đồng để báo cáo thông đồng và đồng thời gửi
tiền để chịu trách nhiệm về báo cáo.

Xử lý sau khi tiết lộ: Sau khi tất cả các kết quả đã cam kết đã được tiết lộ hoặc khoảng thời
gian tiết lộ kết quả đã hết, các kết quả sẽ được so sánh. Nếu tất cả các kết quả đều giống nhau và
không nhận được báo cáo thông đồng nào, những người thực thi đều được đánh giá là trung thực.
Mặt khác, chức năng giải quyết tranh chấp được gọi để khởi chạy một tính toán tin cậy; dựa trên
kết quả tính toán tin cậy, mỗi người thực thi có thể được đánh dấu là trung thực hoặc không
trung thực. Cuối cùng, chức năng phân phối quỹ được gọi để phân phối tiền cọc cho chủ sở hữu
và những người thực thi trung thực.
 IV. Sơ đồ lý thuyết trò chơi và phân tích
Để điều chỉnh các hoạt động trong khuôn khổ được mô tả ở trên, chúng tôi đề xuất các cơ chế
lý thuyết trò chơi được gọi là hợp đồng thuê ngoài. Các cơ chế xác định các tương tác giữa chủ
sở hữu HDSC và người thực thi HDSC, thưởng cho người thực thi trung thực, trừng phạt người
thực thi hành vi sai trái và khuyến khích người thực thi báo cáo thông đồng. Trong phần này,
trước hết chúng tôi trình bày hai hợp đồng thuê ngoài trong Phần IV-A. Hợp đồng đầu tiên chỉ
phản ứng kích hoạt cơ chế tính toán tin cậy khi có sự khác biệt trong kết quả của người thực thi
hoặc hành vi thông đồng được báo cáo; hợp đồng thứ hai tiếp tục chủ động kích hoạt cơ chế tính
toán tin cậy với một xác suất nhất định pfallback , để ngăn chặn hành vi sai trái của người thực thi.
Để phân tích tính bảo mật và hiệu quả của hai hợp đồng này, chúng tôi tiến hành phân tích lý
thuyết trò chơi sau:

● Trong Phần IV-B, chúng tôi phân loại hành vi thông đồng thành hai loại - thông đồng

lành tính và thông đồng ác tính, đồng thời mô hình hóa sự thông đồng của những người
thực thi thành hai loại hợp đồng chung.

● Trong Phần IV-C, chúng tôi phân tích các trò chơi gây ra từ Hợp đồng thuê ngoài thứ

nhất và các hợp đồng thông đồng, đồng thời chỉ ra sự tồn tại của xác suất dương để thông
đồng ác tính thành công; do đó, Hợp đồng thuê ngoài thứ nhất bị lỗi về bảo mật.

● Trong Phần IV-D, chúng tôi phân tích các trò chơi nảy sinh từ hợp đồng thuê ngoài thứ

hai và các hợp đồng thông đồng, và chỉ ra rằng, những người thực thi hợp lý về mặt kinh
c
tế sẽ không tiến hành một sự thông đồng ác tính, miễn là pfallback ≥ trong hợp
n . d executor
đồng thuê ngoài thứ hai, trong đó c là chi phí tính toán, n là số lượng người thực thi và
d executor là tiền cọc của mỗi người thực thi.

Phân tích cho thấy sự cần thiết của việc chủ động khởi chạy cơ chế tính toán tin cậy để ngăn
chặn hành vi sai trái của người thực thi. Nó cũng tiết lộ mối quan hệ giữa n, d executor và pfallback ;
nghĩa là, tần suất sử dụng biện pháp ngăn chặn giảm khi số lượng người thực thi hoặc số tiền cọc
mà người thực thi được yêu cầu tăng lên. Vì vậy, tần suất có thể thấp và do đó, hợp đồng thuê
ngoài thứ hai được đề xuất có thể vừa an toàn vừa hiệu quả. Do giới hạn về không gian, các bằng
chứng được bỏ qua ở đây, nhưng có thể tìm thấy tại [20].

A. Hợp đồng thuê ngoài

Chúng tôi đề xuất hai hợp đồng thuê ngoài sau đây.

1) Hợp đồng thuê ngoài thứ nhất: Hợp đồng bao gồm các giai đoạn sau:

Giai đoạn I – Gửi tiền ban đầu. Chủ HDSC đặt cọc d owner =n . w . Ở đây, w là tiền lương trả
cho mỗi người thực thi công vụ trung thực và nên lớn hơn c để khuyến khích người thực thi công
vụ tham gia. Mỗi người thực thi cũng đặt cọc một khoản tiền d executor , và khoản tiền cọc phải lớn
hơn chi phí cho một cơ chế tính toán tin cậy để thực thi HDSC, được ký hiệu là c full .

Giai đoạn II - Nộp kết quả thi công. Giai đoạn này bắt đầu sau khi tất cả những người thực thi
đã gửi tiền hoặc một khoảng thời gian xác định để gửi tiền đã trôi qua. Giai đoạn này bao gồm
các bước sau. Giai đoạn (i) - Cam kết Kết quả. Trong giai đoạn này, mọi người thực thi gửi một
cam kết đã mã hoá về kết quả thực hiện của nó. Giai đoạn (ii) - Tiết lộ kết quả. Sau khi Giai đoạn
(i) hoàn thành hoặc hết thời hạn quy định cho cam kết, mọi người thực thi sẽ mở cam kết của
mình được đăng trong Giai đoạn (i) để tiết lộ kết quả thực hiện.

Giai đoạn III - Báo cáo ẩn danh về Thông đồng. Giai đoạn này bắt đầu sau khi tất cả những
người thực thi cam kết đã công bố kết quả của họ hoặc thời hạn quy định cho việc công bố kết
quả đã hết. Người thực thi có thể chọn báo cáo ẩn danh thông đồng bằng cách đặt cọc d report =c full
. Danh tính của kẻ thông đồng phản bội này được thể hiện hoàn toàn bằng ID của tài khoản khởi
chạy báo cáo. Lưu ý rằng, ID phải khác và không thể liên kết với ID của người thực thi trong
hợp đồng thuê ngoài, để kẻ phản bội không thể liên kết với bất kỳ người thực thi nào.

Giai đoạn IV - Giải quyết tranh chấp. Giai đoạn này bắt đầu sau khi hết khoảng thời gian
được chỉ định cho Giai đoạn III. Nếu kết quả được tiết lộ bởi tất cả những người thực thi không
giống nhau, thì một lần thực thi tin cậy sẽ được khởi chạy để có được kết quả thực thi chính xác
và chi phí được trả từ khoản tiền cọc của những người thực thi. Mặt khác (nghĩa là tất cả các kết
quả được tiết lộ đều giống nhau), một lệnh thực thi tin cậy vẫn được khởi chạy nếu có một hoặc
nhiều báo cáo ẩn danh về sự thông đồng; trong trường hợp này, chi phí cho việc thực hiện tin cậy
được thanh toán từ các khoản tiền cọc được thực hiện bởi các báo cáo viên.

Giai đoạn V - Phân phối tiền cọc. Có hai trường hợp xảy ra: Trường hợp (i) - Người thực thi
báo cáo kết quả khác nhau. Mỗi người báo cáo thông đồng lấy lại tiền đặt cọc của mình. Những
người thực thi được phát hiện đưa ra kết quả chính xác được đánh dấu là trung thực, trong khi
những người khác được đánh dấu là không trung thực. Nếu tất cả những người thực thi đều
không trung thực thì phần tiền cọc còn lại sẽ do chủ sở hữu HDSC lấy; nếu không, tiền đặt cọc sẽ
được thực hiện đồng đều bởi những người thực thi trung thực. Trường hợp (ii) – Người thực thi
báo cáo kết quả tương tự. Nếu lệnh thực thi tin cậy chưa được khởi chạy hoặc kết quả của người
thực thi được xác định là chính xác bởi quá trình thực thi tin cậy, thì tất cả những người thực thi
đều nhận được số tiền cọc còn lại; nếu không, số tiền cọc còn lại sẽ được những người báo cáo
thông đồng lấy đều.

2) Hợp đồng thuê ngoài thứ hai: Như sẽ trình bày sau, hợp đồng thuê ngoài thứ nhất không
thể ngăn cản những người thực thi gửi một kết quả thực thi không chính xác. Do đó, chúng tôi
tiếp tục đề xuất hợp đồng thuê ngoài thứ hai. Hợp đồng này giống với Hợp đồng thuê ngoài thứ
nhất, ngoại trừ những điểm sau được thêm vào Giai đoạn III: Với xác suất pfallback , là một tham số
hệ thống, chủ sở hữu HDSC giả vờ là người thực thi báo cáo ẩn danh bằng cách đặt cọc
d report =c full . Như sẽ được xử lý sau, xác suất pfallback là một hàm của n . Do không phải tất cả
những người thực thi dự kiến đều có thể tham gia hoàn toàn vào quá trình thực thi, nên n được sử
dụng để xác định pfallback đề cập đến số lượng người thực thi thực tế tham gia hoàn toàn vào quá
trình tính toán. Bằng cách này, sự xáo trộn và thất bại của người thực thi có thể được chấp nhận.
B. Hợp đồng giữa những người thực thi

Những người thực thi ích kỷ về mặt kinh tế có thể thông đồng để tiết kiệm chi phí tính toán của
họ. Dựa trên hậu quả của sự thông đồng, chúng tôi phân loại sự thông đồng làm 2 loại: lành tính
hoặc ác tính. Nếu một sự thông đồng dẫn đến một kết quả chính xác được gửi bởi tất cả những
người thực thi tham gia thông đồng, chúng tôi gọi đó là một sự thông đồng lành tính. Nếu một sự
thông đồng dẫn đến một kết quả không chính xác được gửi bởi tất cả những người thực thi tham
gia thông đồng, thì chúng tôi gọi đó là một sự thông đồng ác tính. Thông đồng lành tính có thể
tiết kiệm chi phí cho người thực thi mà không dẫn đến kết quả thực hiện sai. Do đó, chúng tôi chỉ
nhắm mục tiêu vào việc ngăn chặn sự thông đồng ác tính.

Dựa trên cách mà những người thực thi tương tác với nhau trong một sự thông đồng, chúng tôi
mô tả thêm hành vi của họ và xác định hai loại thông đồng: Thông đồng loại I - một hoặc nhiều
người thực thi cung cấp một kết quả, được hứa hẹn là đúng, cho những người thực thi khác; đổi
lại, người sau cung cấp cho người trước một phần thưởng, phần thưởng này nhỏ hơn chi phí họ
phải trả nếu trực tiếp thực hiện phép tính. Thông đồng loại II - một hoặc nhiều người thực thi đề
xuất một kết quả, có thể đúng hoặc không, và yêu cầu những người thực thi khác nộp cùng một
kết quả; để đảm bảo người sau thông đồng, người trước hứa sẽ thưởng hối lộ cho người sau nếu
họ làm như vậy, trong khi đó người sau được yêu cầu đặt cọc và sẽ mất số tiền đặt cọc nếu họ
không thực hiện.

Sau đây, chúng tôi mô tả các hợp đồng chung cho hai loại thông đồng này.

1) Hợp đồng thông đồng loại I: Chúng tôi gọi một người thực thi là người lãnh đạo (ký hiệu
là LDR) nếu người đó hứa sẽ thực hiện HDSC và chia sẻ kết quả cho những người khác. Có thể
có nhiều nhà lãnh đạo; để đơn giản, chúng tôi cho rằng chỉ có một nhà lãnh đạo duy nhất. Chúng
tôi gọi những người thực thi khác tham gia thông đồng là những người theo dõi (được ký hiệu là
FLR mỗi người). Tương tác thông đồng bao gồm ba giai đoạn sau, trong đó Giai đoạn I và II của
hợp đồng này sẽ diễn ra sau Giai đoạn I và trước Giai đoạn II của các hợp đồng thuê ngoài, trong
khi Giai đoạn III của hợp đồng này sẽ diễn ra sau Giai đoạn V của các hợp đồng thuê ngoài.

Giai đoạn I – Tiền gửi ban đầu. LDR thực hiện đặt cọc d LDR. Mỗi FLR cũng tạo một khoản tiền
cọc d FLR, trong đó d FLR ≤ c; tức là tiền đặt cọc, sẽ được thưởng cho người đứng đầu nếu kết quả
cung cấp là chính xác, không được lớn hơn chi phí tự mình thực hiện HDSC một cách trung
thực.

Giai đoạn II - Chuẩn bị kết quả thực hiện. Giai đoạn này bao gồm ba bước sau. Bước (i) - LDR
Chuẩn bị Kết quả. LDR thực hiện HDSC một cách trung thực để có được kết quả đúng r với xác
suất là p LDR; hoặc nếu không nó tạo nên một kết quả r ' ngẫu nhiên. Bước (ii) - LDR Chia sẻ Kết
quả cho Người theo dõi. LDR chia sẻ kết quả chuẩn bị của nó, là r hoặc r ' , cho những người theo
dõi. Bước (iii) - Người theo dõi chuẩn bị Kết quả của họ. Đối với mỗi FLR, nó thực hiện HDSC
một cách trung thực để có được kết quả chính xác với xác suất là p FLR; hoặc nó trực tiếp sử dụng
kết quả được chia sẻ bởi LDR.

Giai đoạn III - Phân phối tiền cọc. Nếu kết quả do LDR chia sẻ được chấp nhận là đúng trong
hợp đồng thuê ngoài, thì LDR sẽ nhận toàn bộ tiền đặt cọc; mặt khác, tiền cọc được phân bổ đều
cho những người theo dõi.

Trong hợp đồng này, người lãnh đạo có nhiệm vụ cung cấp kết quả chính xác. Nếu người lãnh
đạo làm như vậy, tất cả những người theo dõi nên cùng nhau thưởng cho người lãnh đạo bằng
cách đưa tiền cọc của họ cho người lãnh đạo. Bằng cách này, chỉ một phép tính được thực hiện
bởi người lãnh đạo và tất cả người thực thi chia sẻ chi phí tính toán, thay vì mọi người thực thi
lặp lại cùng một phép tính nhiều lần; do đó, chi phí tính toán tổng thể của họ được giảm.

Tuy nhiên, nếu người lãnh đạo cung cấp một kết quả không chính xác, những người theo dõi
sử dụng kết quả đó có thể bị tổn hại. Nghĩa là, nếu phát hiện kết quả không chính xác trong hợp
đồng thuê ngoài, mọi người theo dõi sử dụng kết quả đó sẽ bị mất tiền đặt cọc d executor . Để bảo vệ
những người theo dõi khỏi mất mát như vậy, việc đặt tiền cọc của người lãnh đạo như sau là hợp
lý về mặt kinh tế:

d LDR= ( n−1 ) •d executor ,(1)

Bằng cách này, nếu người lãnh đạo cung cấp một kết quả không chính xác và hành vi sai trái
này bị phát hiện, người lãnh đạo sẽ phải trả giá cho sự mất mát của mọi người theo dõi trong hợp
đồng thông đồng này. Chúng tôi gọi hợp đồng Thông đồng Loại I là hợp đồng Thông đồng Loại
I có tính công bằng nếu d LDR được đặt như trong Phương trình (1).

Ngoài ra, Thông đồng Loại I có thể lành tính nếu người lãnh đạo cung cấp kết quả chính xác
hoặc ác tính nếu người lãnh đạo đưa ra kết quả không chính xác và tất cả những người theo dõi
đều đưa ra kết quả giống nhau.

2) Hợp đồng thông đồng loại II: Tương tự như thông đồng loại I, ta gọi người thực thi đề
xuất kết quả thực hiện là lãnh đạo (ký hiệu là LDR), gọi những người khác trong thông đồng là
người theo dõi (ký hiệu là FLR mỗi người) và giả sử chỉ có một người lãnh đạo cho đơn giản.
Người lãnh đạo đưa ra một kết quả thực hiện r ' và hứa thưởng cho những người theo dõi miễn là
tất cả họ đều sử dụng kết quả này để nộp và kết quả được chấp nhận là đúng trong hợp đồng thuê
ngoài. Hợp đồng bao gồm ba giai đoạn, trong đó cũng tương tự như Hợp đồng Thông đồng Loại
I, Giai đoạn I và II của hợp đồng này sẽ diễn ra sau Giai đoạn I và trước Giai đoạn II của hợp
đồng thuê ngoài, trong khi Giai đoạn III của hợp đồng này sẽ diễn ra sau Giai đoạn V của hợp
đồng thuê ngoài.

Giai đoạn I - Gửi tiền ban đầu. LDR đặt cọc d LDR + ( n−1 ) .b và mỗi FLR đặt cọc d FLR. Ở đây, b
đại diện cho số tiền hối lộ mà LDR hứa thưởng cho mỗi FLR thực hiện theo thông đồng.

Giai đoạn II - Chuẩn bị kết quả thực hiện. Giai đoạn này bao gồm các bước sau. Bước (i) -
LDR Chia sẻ Kết quả cho Người theo dõi. LDR tạo ra một kết quả thực thi r ' và chia sẻ nó với
những người theo dõi. Bước (ii) - Người theo dõi chuẩn bị kết quả của họ. Đối với mỗi người
theo dõi FLR, nó thực hiện trung thực HDSC để lấy và sau đó báo cáo kết quả chính xác với xác
suất là p FLR; hoặc nó trực tiếp sử dụng kết quả được chia sẻ bởi LDR.

Giai đoạn III - Phân phối Tiền cọc. Có các trường hợp khác nhau sau đây: Trường hợp (i) - Ít
nhất một người thực thi bị phát hiện phản bội thông đồng bằng cách báo cáo một kết quả khác
với r ' . Có nhiều cách khác nhau để phân phối tiền đặt cọc, nhưng tất cả đều có chung những điểm
sau: mỗi người thực thi hành vi phản bội thông đồng sẽ mất tiền đặt cọc trong hợp đồng thông
đồng; Mỗi người thực thi không phản bội có thể lấy lại tiền đặt cọc của mình và tiếp tục nhận hối
lộ nếu đó là người theo dõi. Trường hợp (ii) - Tất cả người thực thi báo cáo r ' , và kết quả được
chấp nhận là đúng. LDR lấy d LDR và mọi FLR lấy d FLR +b . Trường hợp (iii) - Tất cả những
người thực thi đều khai báo r ' nhưng phát hiện có thông đồng (vì có báo cáo thông đồng).
Không ai có thể được xác định là kẻ phản bội thông đồng do tính ẩn danh trong báo cáo. Do đó,
có hai cách tiếp cận để phân phối tiền cọc. Trong cách tiếp cận đầu tiên, tiền cọc được phân phối
như trong trường hợp trước; trong cách tiếp cận thứ hai, không ai trong số những người thực thi
nhận được tài trợ từ các khoản tiền cọc. Dễ dàng thấy rằng, khi phương pháp đầu tiên được thực
hiện, nó không phải là Cân bằng Nash khi không có người thực thi nào báo cáo về sự thông đồng
vì bất kỳ người thực thi nào phản bội đều có thể đạt được mức thỏa dụng cao hơn. Do đó, ở đây
chúng tôi chỉ xem xét rằng cách tiếp cận thứ hai được thông qua.

Như chúng ta có thể thấy, một sự thông đồng Loại II là ác ý nếu nó thành công, bởi vì nó sẽ
dẫn đến một kết quả thực thi không chính xác được chấp nhận.
 C. Phân tích I: Hợp đồng thuê ngoài thứ nhất v.s. thông đồng

Trong tiểu mục này, chúng tôi phân tích các trò chơi do hợp đồng thuê ngoài thứ nhất gây ra và
hai loại thông đồng tương ứng. Mục đích là để chỉ ra rằng, với hợp đồng thuê ngoài thứ nhất, trò
chơi có thể chấm dứt khi có sự thông đồng ác tính.

Hình 1: Trò chơi tạo ra bởi hợp đồng thuê ngoài thứ nhất và hợp đồng Thông đồng Loại I. Ở
đây, u LDR và u FLR lần lượt biểu thị các hàm ích lợi của LDR và FLR; n 0 là số người thực hiện
tính kết quả và nộp r ; n1 là số người thực hiện nộp kết quả r ' nhận được từ LDR; Mà còn,
d LDR n1 d executor−c full
u5 , L =−d executor −d LDR và u5 , F =w−c + +
n−1 n0

1) Hợp đồng thuê ngoài thứ nhất v.s. Thông đồng Loại I: Hình 1 minh họa Trò chơi 1,
được gây ra bởi Hợp đồng thuê ngoài thứ nhất và hợp đồng Thông đồng Loại I. Lưu ý rằng,
chúng tôi không hiển thị các nhánh có báo cáo thông đồng bởi vì, trong thông đồng Loại I, chiến
lược báo cáo bị chi phối bởi chiến lược kiểm tra và gửi kết quả chính xác.
 Trong trò chơi 1, không có chiến lược chiếm ưu thế thuần túy nào cho LDR hoặc mỗi FLR.
Khi LDR đưa ra r , bất kể người theo dõi thực hiện hành động gì, nó luôn nhận được phần thưởng
là w−c +(n−1)d FLR . Khi LDR gửi r ' , nó có thể nhận được −d LDR−d exexecutor hoặc w +(n−1)d FLR
tùy thuộc vào việc người theo dõi có tính toán và gửi r một cách trung thực hay không. Vì
w +(n−1)d FLR > w−c+(n−1) d FLR >−d FLR −d exexecutor , nên LDR sẽ sử dụng chiến lược hỗn hợp
thay vì chiến lược thuần túy để tối đa hóa lợi nhuận của mình. Tương tự, đối với mỗi FLR, một
chiến lược hỗn hợp tạo ra nhiều lợi nhuận hơn một chiến lược thuần túy. Bổ đề 1 sau đây đưa ra
Cân bằng Nash của Trò chơi 1 và xác suất dương mà trò chơi kết thúc do một sự thông đồng ác
tính.

TỰ PHÂN TÍCH:
Ở đây, LDR có hai cách thực thi: một là cung cấp và nộp kết quả r (kết quả đúng với xác suất
p LDR), hai là cung cấp và nộp kết quả r ' (kết quả sai với xác suất là 1− p LDR). Và với mỗi cách
thực thi LDR thì FLR cũng có hai cách thực thi: một là kiểm tra rồi nộp kết quả (với xác suất
p FLR) và hai là không kiểm tra rồi nộp kết quả (với xác suất 1− p FLR).

Trường hợp v3 : LDR cung cấp, nộp kết quả r (kết quả đúng với xác suất p LDR) và FLR kiểm tra
rồi nộp kết quả r (với xác suất p FLR). Trong trường hợp này, hàm lợi ích của LDR là
u LDR =w−c +(n−1)d FLR, nghĩa là hàm lợi ích bằng tiền thưởng do cung cấp kết quả chính xác trừ
đi chi phí thực thi HDSC cộng với tiền cọc của tất cả những người theo dõi. Còn hàm lợi ích của
FLR là u FLR=w−c−d FLR, tương đương tiền thưởng do cung cấp kết quả chính xác trừ đi chi phí
thực thi HDSC và tiền cọc cho thông đồng. Tương tự với trường hợp v 4.

Giờ cùng đến với trường hợp LDR cung cấp và nộp kết quả không chính xác r ' (với xác suất là
1− p LDR ). Với trường hợp v5 , FLR sẽ kiểm tra và nhận ra kết quả này sai nên họ sẽ nộp kết quả
đúng r (với xác suất p FLR). Khi đó, hàm lợi ích của LDR bằng u5 , L =−d executor −d LDR, họ sẽ mất
tiền cọc cho HDSC do trả về kết quả sai và cả tiền cọc trong thông đồng loại I. Còn với FLR thì
hàm ích lợi sẽ bằng tiền thưởng khi thực thi HDSC trừ đi chi phí thực thi cộng với một phần tiền
cọc của LDR do đã cung cấp kết quả sai (số tiền cọc chia cho số người theo dõi) cộng với tiền lãi
thu được (bằng hiệu của tổng tiền cọc thực thi của những người nộp kết quả sai và chi phí để
chạy tính toán đáng tin cậy, chia cho số người nộp kết quả đúng).

Trong trường hợp v 6, FLR sẽ không kiểm tra và nộp kết quả sai r ' nên chúng ta sẽ có hai khả
năng là trong số các FLR có ít nhất một người kiểm tra hoặc không có bất kì người nào kiểm tra.
Trường hợp có ít nhất một người kiểm tra v7 , hàm ích lợi của LDR giống như trường hợp v5 còn
FLR sẽ mất tiền thực thi nhưng nhận được 1 phần tiền cọc của LDR. Với v 8, do không có ai kiểm
tra lại nên không ai biết là kết quả sai suy ra không hề có báo cáo thông đồng. Do đó, tính toán
tin cậy sẽ không được khởi chạy nên kết quả r ' vẫn được chấp nhận cho dù nó là kết quả sai. Khi
đó, LDR sẽ thu về tiền thưởng khi thực thi HDSC và tổng tiền cọc của tất cả người theo dõi. Còn
về FLR thì họ sẽ nhận được tiền thưởng và mất tiền cọc trong thông đồng.

Vậy như ta đã thấy trường hợp v 8, LDR thu lại được lợi nhuận tốt đa. Nhưng điều này cực kì
khó xảy ra vì hết hiếm khi không có bất kì một FLR nào kiểm tra kết quả mà họ nhận được từ
LDR, đồng nghĩa với việc tất cả FLR đều tin tưởng tuyệt đối vào LDR. Điều đó rất khó có thể
xảy ra với một số lượng người khổng lồ trong mạng blockchain. Còn đối với các FLR thì họ sẽ
có xu hướng hướng tới ba khả năng để tối ưu hoá lợi nhuận của họ, đó là trường hợp v 4 , v 8 và v5 .
Trường họp v 8 thì như đã nói ở trên, nó rất khó xảy ra. Trường hợp v 4 thì có khả năng xảy ra cao
hơn nhưng trong trường hợp này, FLR hoàn toàn phụ thuộc vào LDR (chỉ khi LDR cung cấp kết
quả chính xác). Với trường hợp v5 , số tiền thu được của FLR càng lớn khi số lượng người đưa ra
kết quả sai càng lớn hoặc số lượng người nộp kết quả đúng càng nhỏ. Nói cách khác, lợi nhuận
của FLR tỉ lệ thuận với số lượng người nộp kết quả sai n1 và tỉ lệ nghịch với số lượng người nộp
kết quả đúng n 0. Vậy FLR đạt được lợi nhuận tối đa khi n 0=1 và n1 =n−1 khi đó
d LDR
u FLR=w−c+ +(n−1)d executor −c full . Và nếu trong trường hợp thông đồng loại I có tính công
n−1
bằng thì u FLR=w−c+ n . d executor−c full.

Bổ đề 1: Một chiến lược hỗn hợp α =( α LDR , α FLR ) =¿, ( p FLR r ,(1− p FLR )r ' )¿ là Cân bằng Nash
của Trò chơi 1 trong Hình 1 trong đó

n−1 c
(1− p FLR ) =1−
w +d exexecutor +d LDR +(n−1)d FLR

c
p LDR=1−
n d exexecutor −c full n−2 d LDR
w+ −(1− p FLR ) (w+ d exexecutor −d FLR − )
n1 n−1

Ngoài ra, cả p FLR và p LDR đều nằm trong (0 ; 1); do đó, có một xác suất dương
( 1− p LDR ) .(1− pFLR ) rằng Ván 1 kết thúc do thông đồng ác tính.
 Xác suất để FLR chọn trường hợp v 8 bằng phần bù của tỉ số của chi phí thực thi với toàn bộ số
tiền mà LDR thu được trong trường hợp v 8.

Xác suất LDR đưa ra kết quả đúng là phần bù của tỉ số của chi phí thực thi với tiền thưởng
thực thi cộng với (tổng tiền cọc thực thi trừ đi chi phí tính toán tin cậy chia đều cho số người nộp
r nhận được từ LDR ) trừ đi (xác suất xảy ra v 8 nhân với (tiền thưởng cộng tiền cọc thực thi trừ
'

đi tiền cọc FLR và tiền cọc LDR chia đều cho FLR))

p FLR 1− p FLR
LDR\FLR
r r
'

p LDR r u3 , L =w−c +( n−1)d FLR u3 , F =w−c−d FLR u 4 , L=w−c+(n−1) d FLR u4 , F =w−d FLR

1−( 1− pFLR )n−2 ( 1− p FLR )

n−2

d LDR n1 d executor −c full

1− p LDR r' u5 , L =−d exexecutor −d FLR u5 , F =w−c+ +
n−1 n0 d
u7 , L =−d u LDR
exexecutor −d LDR u 7 , F=−d exexecutor +8 , L
=w +(n−1)d FLR u8 , F =w
n−1

Lợi ích kỳ vọng của LDR là:

[
L ( p LDR , p FLR ) =p LDR [ p FLR u3 , L + ( 1− pFLR ) u4 , L ]+ ( 1− p LDR ) p FLR u5 , L + ( 1− p FLR ) (( 1−( 1− pFLR )
n−2
) u7 , L+( 1− pFLR )n−2 u 8

[
→ L ( p LDR , p FLR )= p LDR pFLR u3 ,L + p LDR ( 1− pFLR ) u4 , L + ( 1− p LDR ) p FLR u5 , L + ( 1−p FLR ) ( u7 , L + ( 1− p FLR )
n−2
( u8 , L −u7 , L ) ) ]

→ L ( p LDR , p FLR )= p LDR pFLR u3 ,L + p LDR ( 1− pFLR ) u4 , L + ( 1− p LDR ) [ p FLR u5 , L + ( 1− p FLR ) u7 ,L + ( 1− p FLR )n −1 ( u8 , L −u7 , L ) ]

→ L ( p LDR , p FLR )= p LDR pFLR u3 ,L + p LDR ( 1− pFLR ) u4 , L + ( 1− p LDR ) pFLR u 5 ,L + ( 1− p LDR ) ( 1−p FLR ) u 7 , L + ( 1− p LDR ) ( 1−p FL

dL ( p LDR , p FLR ) n−1

= p FLR u3 , L + ( 1−p FLR ) u 4 , L −p FLR u5 , L −( 1− p FLR ) u7 ,L −( 1−p FLR ) ( u 8 , L−u 7 , L )
d p LDR

dL ( p LDR , p FLR )
→ =p FLR u3 , L + u4 , L − p FLR u 4 , L − pFLR u 5 ,L −u7 ,L + pFLR u7 , L−( 1− pFLR )n−1 ( u 8 , L−u 7 , L )
d p LDR
 dL ( p LDR , p FLR ) n−1
→ =u4 , L −u7 , L −( 1− p FLR ) ( u 8 ,L −u7 ,L )=0
d p LDR

n−1 u4 , L−u 7 , L w−c+ ( n−1 ) d FLR +d exexecutor +d LDR

→ ( 1− p FLR ) = =
u8 , L −u7 , L w+(n−1)d FLR +d exexecutor +d LDR

n−1 c
→(1− p FLR ) =1−
w +d exexecutor +d LDR +( n−1)d FLR

Lợi ích kỳ vọng của FLR là:

[
F ( p LDR , pFLR )= p FLR [ p LDR u3 , F + ( 1− p LDR ) u 5 ,F ] + ( 1− p FLR ) p LDR u 4 , F + ( 1− pLDR ) ( ( 1−( 1−p FLR )
n−2
) u7 , F + ( 1− pFLR )n−2 u

[
→ F ( pLDR , p FLR ) = pFLR p LDR u3 , F + p FLR ( 1− p LDR ) u5 , F + ( 1− p FLR ) p LDR u4 ,F + ( 1− p LDR ) ( u7 , F + ( 1−p FLR )
n−2
( u 8 , F−u 7 , F ) )

→ F ( pLDR , p FLR ) = pFLR p LDR u3 , F + p FLR ( 1− p LDR ) u5 , F + ( 1− p FLR ) [ p LDR u4 , F + ( 1− p LDR ) u7 , F + ( 1− p LDR ) ( 1− p FLR )
n −2
( u8 ,

→ F ( pLDR , p FLR ) = pFLR p LDR u3 , F + p FLR ( 1− p LDR ) u5 , F + ( 1− p FLR ) pLDR u 4 , F + ( 1− pFLR ) ( 1− p LDR ) u7 , F + ( 1− p LDR ) ( 1− p F

dF ( p LDR , pFLR ) n−2

= pLDR u 3 , F + ( 1− p LDR ) u5 , F − p LDR u4 , F −( 1−p LDR ) u 7 , F−( n−1 ) ( 1− p LDR ) ( 1− p FLR ) ( u 8 ,F −u7 , F )
d p FLR

dF ( pLDR , p FLR ) n−2

→ = p LDR u3 , F +u 5 , F− p LDR u5 , F − pLDR u 4 , F −u7 , F + p LDR u7 , F −( n−1 ) ( 1−p LDR ) ( 1− p FLR ) ( u8 , F −u7 , F )
d p FLR

dF ( pLDR , p FLR ) n−2

→ = p LDR u3 , F +u 5 , F− p LDR u5 , F − pLDR u 4 , F −u7 , F + p LDR u7 , F −( n−1 ) ( 1−p FLR ) ( u 8 , F−u 7 , F ) + p LDR ( n−
d p FLR
n−2 n−2
u5 , F −u7 , F −( n−1 ) ( 1−p FLR ) ( u 8 ,F −u 7 ,F )=−p LDR u3 , F + p LDR u 4 , F + p LDR u5 , F −p LDR u 7 , F− p LDR ( n−1 ) ( 1−p FLR ) (u8

u 5 ,F −u7 ,F −( n−1 ) ( 1− pFLR )n−2 ( u8 , F −u7 , F )

→ p LDR =
−u3 , F +u 4 , F +u5 , F −u7 , F −( n−1 ) ( 1−p FLR )n−2 ( u 8 , F−u 7 , F )

u 3 ,F −u 4 , F
→ p LDR =1+
−u3 , F +u 4 , F +u5 , F −u7 , F −( n−1 ) ( 1−p FLR )n−2 ( u 8 ,F −u 7 ,F )
 w−c−d FLR −( w−d FLR )
→ p LDR =1+ n−2
−u3 , F +u 4 , F +u5 , F −u7 , F −( n−1 ) ( 1−p FLR ) ( u 8 ,F −u 7 ,F )
w−c−d FLR −( w−d FLR )
→ p LDR =1+
−( w−c−d FLR ) + w−d FLR + w−c +
d LDR n 1 d executor −c full
n−1
+
n0 ( d
) n−2
− −d exexecutor+ LDR −( n−1 ) ( 1− p FLR ) ( u8 , F
n−1

−c
→ p LDR =1+
n1 d executor −c full n−2
w+ + d exexecutor −( n−1 ) ( 1−p FLR ) ( u 8 , F−u 7 , F )
n0

c
→ p LDR =1−
n 1 d executor −c full n−2
w+ +d exexecutor −( n−1 ) ( 1− p FLR ) ( u8 , F −u7 , F )
n0

c
→ p LDR =1−
w+
( n1+ n0 ) d executor −c full
n0 (
−( n−1 ) ( 1− p FLR )n−2 w−d FLR − −d exexecutor + ( d LDR
n−1 ))
c
→ p LDR =1−
w+
n d executor −c full
n0
−( n−1 ) ( 1− p FLR )
n−2
(
w+ d exexecutor −d FLR−
d LDR
n−1 )

2) Hợp đồng thuê ngoài thứ nhất v.s. Thông đồng Loại II: Hình 2 minh họa Trò chơi 2,
được tạo ra bởi Hợp đồng thuê ngoài thứ nhất và hợp đồng Thông đồng Loại II, và Bảng I cho
thấy các chiến lược và hàm ích lợi tương ứng cho LDR và từng FLR trong Trò chơi 2.
Hình 2: Trò chơi tạo bởi hợp đồng thuê ngoài thứ nhất và hợp đồng Thông đồng Loại II.

LDR có thể bắt đầu thông đồng hoặc không. Nếu một thông đồng được khởi tạo, mỗi FLR có
thể thông đồng hoặc không thông đồng. Khi một sự thông đồng được thiết lập, LDR và mỗi FLR
có thể báo cáo sự thông đồng một cách ẩn danh hoặc không. LDR có thể gửi kết quả tính toán
chính xác r hoặc kết quả giả đồng mức r ' . Ngoài ra, mỗi FLR có thể tính toán trung thực và gửi r
hoặc gửi r ' do LDR cung cấp.

Bảng I: Hợp đồng thuê ngoài thứ nhất v.s. Thông đồng Loại II: Chiến lược và Tiện ích
 Bảng I cho thấy biểu diễn dạng chuẩn của trò chơi. LDR có năm chiến lược là ¬init ,
init . r .¬ report , init . r ' . ¬ report , init . r . report và init . r ' . report . Mỗi FLR có năm chiến lược là :
¬ collude, collude . r . ¬report , collude . r ' .¬ report , collude . r . report và collude . r ' .report . Mỗi
cột tương ứng với một chiến lược của LDR và mỗi hàng tương ứng với một chiến lược của từng
FLR.

Bảng I cũng trình bày các tiện ích của LDR và mỗi FLR dưới mỗi hồ sơ chiến lược trong ô
tương ứng, trong đó hàng đầu tiên trong ô là tiện ích của LDR và hàng thứ hai là của FLR. Các
ký hiệu sau đây được giới thiệu để đơn giản hóa việc trình bày:

● z=w – c ;

● d e =d exexecutor;

● d l=d LDR +(n−1) b ;

● d f =d FLR;

m2 d exexecutor −c full
● b 1= ;
m1

m2 d exexecutor −c full
● b 2= ;
m0

c full
● b 3= ;
m0

m1 d f
● b 4=−(m 2−1)b+ ;
m2

d l+(m1−1)d f
● b 5= ;
m2

m1 d f
● b 6=b+ ;
m2
 ● m0 là số người thực thi báo cáo thông đồng;

● m 1 là số người thực thi nộp r ;

● m2 là số người thực thi nộp r .

'

Lưu ý rằng, giá trị của m 1 và m2 có thể ảnh hưởng đến phần thưởng theo một số chiến lược;
trong những trường hợp đó, ô được chia thành nhiều cột. Cân bằng Nash với phần thưởng tối đa
được in đậm.

Dựa trên Bảng I, chúng ta có Bổ đề 2 sau đây. Theo trực quan, Bổ đề nói rằng, theo một số cấu
hình nhất định của hợp đồng thông đồng mà những người thực thi có thể kiểm soát, Trò chơi 2
có thể kết thúc ở trạng thái cân bằng khi những người thực thi thành công trong một sự thông
đồng ác tính.

TỰ PHÂN TÍCH:
Khởi đầu, LDR có thể chọn triển khai thông đồng hay không. Và FLR có thể chọn thông đông
hoặc không. Khi thông đồng được triển khai, LDR và mỗi FLR có thể báo cáo thông đồng hoặc
không. Ta có bảng I thể hiện hàm ích lợi của LDR và FLR trong mỗi trường hợp khác nhau. Cụ
thể, LDR và FLR đều có năm chiến lược nên ở đây chúng ta có tổng cộng 25 trường hợp.
Nhưng, đối với các trường hợp LDR không triển khai thông đồng hay FLR không tham gia thông
đồng thì họ đều có chung một hàm ích lợi bằng z=w – c . Nên ở đây chúng ta chỉ làm rõ các
trường hợp LDR và FLR thông đồng. Chúng ta chia làm bốn tình huống, với tình huống I ta xem
xét toàn bộ trường hợp không có báo cáo thông đồng, tình huống II là trường hợp LDR và FLR
đều thực hiện báo cáo thông đồng, tình huống III là trường hợp LDR không thực hiện báo cáo
thông đồng để FLR thực hiện và tình huống IV là trường hợp LDR thực hiện báo cáo thông đồng
còn FLR thì không. Với tình huống I, chúng ta có m 0=0, còn với các tình huống còn lại thì m0 >0
.
 Đầu tiên, chúng ta hãy xem tình huống I bao gồm v5 và tập con của nó (
v7 , v 8 , v 11 , v 12 , v 13 , v 14 , v 19 , v 20 ). Bắt đầu với v7 và tập con của nó ( v11 , v 12) là trường hợp LDR tính
toán và nộp r .

v11 : Chiến lược của LDR là init . r .¬ report , của FLR là collude . r . ¬report . Trong trường hợp
này, chúng ta sẽ chia ra hai trường hợp nhỏ, không có bất kì FLR nào và tồn tại FLR nộp r ' .
Trước tiên, ta sẽ xem xét trường hợp không có FLR nào nộp r ' (hay m2=0 ), thì hàm ích lợi của
LDR, u LDR =z−d l=w−c−d LDR−( n−1 ) b, ở đây LDR thu được tiền thưởng nhưng sẽ mất phí
thực thi và tiền cọc thông đồng loại II. Còn đối với FLR, u FLR=z −d f =w−c−d FLR, nghĩa là mỗi
FLR cũng thu được tiền thưởng và mất chi phí thực thi, tiền cọc thông đồng loại II. Với trường
hợp có ít nhất một FLR nộp r ' (hay m2 >0), cũng như trường hợp trước nhưng cả LDR và FLR
m 2 d exexecutor −c full
đều thu thêm được một khoản tiền lãi b 1= , là khoản tiền cọc cho HDSC của tất
m1
cả những người nộp r ' trừ đi chi phí chạy tính toán tin cậy và chia đều cho những người nộp kết
quả đúng.

v12 : Ta xem xét những FLR nộp r ' trong trường hợp m2 >0 ở trên. Do trong trường hợp này, chỉ
thay đổi chiến lược của FLR nên hàm ích lợi của LDR vẫn được giữ nguyên. Thay vào đó, hàm
ích lợi của FLR là
d l +(m1−1) d f d + ( n−1 ) b+(m 1−1)d FLR
u FLR=−d e + b5=−d exexecutor + =−d exexecutor + LDR , các FLR
m2 m2
mất tiền cọc cho HDSC do nộp kết quả sai nhưng nhận được một khoản tiền lãi (bằng tổng của
tiền cọc của LDR và số tiền cọc của những FLR nộp r chia đều cho những FLR nộp r ' ).

Giờ ta xét trường hợp LDR nộp r ' bao gồm v 8 và tập con của nó ( v13 , v 14 , v 19 , v 20).

v13 : Ở trường hợp này ta sẽ xét chiến lược của FLR được giữ nguyên như ở v11 (
collude . r . ¬report ), LDR sẽ thay đổi và sử dụng chiến lược init . r ' . ¬ report . Nên hàm ích lợi
của FLR được giữ nguyên như ở trường hợp m2 >0 ở v11 , còn LDR là
m1 d f m d
u LDR =−d e + b4 =−d exexecutor −( m 2−1 ) b+ =−d exexecutor −( m2−1 ) b+ 1 FLR . LDR mất tiền cọc
m2 m2
thực thi, tiền hối lộ cho những FLR làm theo hợp đồng thông đồng và thu được một khoản tiền
lãi sinh ra do những FLR làm trái hợp đồng thông đồng (tiền cọc của những FLR nộp r chia đều
cho những FLR nộp r ' ).

v14 : Chiến lược của LDR là init . r ' . ¬ report , của FLR là collude . r ' .¬ report . Trong chiến lược
này, hàm ích lợi có hai trường hợp, không có bất kì FLR nào ( v19 ) và có ít nhất một FLR ( v 20)
nộp r . Với trường hợp không có bất kì FLR nào nộp r (hay m 1=0 ), LDR có hàm ích lợi
u LDR =w−( n−1 ) b . Ở đây, LDR thu được tiền thưởng và chỉ mất tiền hối lộ cho tất cả FLR, còn
LFR vừa thu được tiền thưởng vừa được tiền hối lộ từ LDR. Đây là trường hợp tối ưu nhất cho
mọi LDR và FLR. Nhưng trong trường hợp ngược lại (hay m1 >0), nghĩa là tồn tại FLR nộp r ,
hàm ích lợi của LDR giống với trường hợp v14 , FLR mất tiền cọc thực thi và thu được tiền hối lộ,
tiền lãi do những FLR làm sai hợp đồng sinh ra; hàm ích lợi
m1 d f m1 d FLR
u LDR =−d e + b6=−d exexecutor +b+ =−d exexecutor +b+ .
m2 m2

Tiếp theo, ta xét tình huống II bao gồm v6 và tập con của nó (
v 9 , v10 , v 15 , v 16 , v 17 , v 18 , v 21 , v 22 , v 23 , v 24 ). Bắt đầu với v 9 và tập con của nó ( v15 , v 16 , v 21 , v 22) là
trường hợp LDR tính toán và nộp r .

v15 : Chiến lược của LDR là init . r . report , của FLR là collude . r . report . Trong trường hợp này,
chúng ta sẽ chia ra hai trường hợp nhỏ, không có bất kì FLR nào và tồn tại FLR nộp r ' . Trước
tiên, ta sẽ xem xét trường hợp không có FLR nào nộp r ' (hay m2=0 ), thì hàm ích lợi,
c full c full
u LDR =z−d l−b 3=w−c−d LDR −( n−1 ) b− và u FLR=z −d f −b3 =w−c−d FLR− , ở đây LDR
m0 m0
và FLR đều nhận được tiền thưởng HDSC và mất chi phí thực thi, tiền cọc thông đồng và chi phí
chạy tính toán tin cậy (chia đều cho số người thực thi báo cáo thông đồng). Với trường hợp có ít
m 2 d exexecutor −c full
nhất một FLR nộp r ' (hay m2 >0), u LDR =z−d l +b1=w−c−d LDR −( n−1 ) b+ và
m1
m2 d exexecutor −c full
u FLR=z −d f + b1=w−c −d FLR + , ở đây LDR và FLR đều nhận được tiền thưởng
m1
HDSC, tiền lãi từ FLR nộp kết quả sai (tiền cọc cho HDSC của tất cả FLR r ' trừ đi chi phí chạy
tính toán tin cậy và chia đều cho những người nộp kết quả đúng) và mất chi phí thực thi, tiền cọc
thông đồng. Điểm khác duy nhất giữa hai hàm ích lợi của LDR và FLR trong cả hai trường hợp
là LDR mất thêm tiền hối lộ trong tiền cọc thông đồng.

v16 : Ta xem xét những FLR nộp r ' trong trường hợp m2 >0 ở trên. Do trong trường hợp này, chỉ
thay đổi chiến lược của FLR nên hàm ích lợi của LDR vẫn được giữ nguyên. Thay vào đó, hàm
ích lợi của FLR là u FLR=−d e + b5, giống với FLR trong trường hợp v12 .

Giờ ta xét trường hợp LDR nộp r ' bao gồm v10 và tập con của nó ( v17 , v 18 , v 23 , v24 ).

v17 : Ở trường hợp này ta sẽ xét chiến lược của FLR được giữ nguyên như ở v15 (
collude . r . report ), LDR sẽ thay đổi và sử dụng chiến lược init . r ' . report . Nên hàm ích lợi của
FLR được giữ nguyên như ở trường hợp m2 >0 ở v15 , còn LDR là u LDR =−d e + b4 tương đương với
LDR ở v13 .

v18 : Chiến lược của LDR là init . r ' . report , của FLR là collude . r ' .report . Trong chiến lược
này, hàm ích lợi có hai trường hợp, không có bất kì FLR nào ( v 23) và có ít nhất một FLR ( v 24)
nộp r . Với trường hợp ngược lại (hay m1 >0), hàm ích lợi của LDR và FLR đều y hệt với trường
hợp v14 . Nhưng trường hợp không có bất kì FLR nào nộp r (hay m1=0 ), có hàm ích lợi
m2 d exexecutor −c full
u LDR =−d l−de +b 2=−d LDR−(n−1) b−d exexecutor + ,
m0
m2 d exexecutor −c full
u FLR=−d f −d e + b2=−d FLR −d exexecutor + . Ở đây, LDR và FLR đều mất toàn bộ
m0
tiền cọc hợp đồng thông đồng, tiền cọc thực thi và thu được tiền lãi b 2 (bằng tổng của tiền cọc
của LDR và số tiền cọc của những FLR nộp r chia đều cho số người thực thi báo cáo thông
đồng).

Tiếp theo, ta xét tình huống III, IV tương tự.

Bổ đề 2: Khi d LDR ≥(n−1)d executor , d FLR ≥(n−1)d executor và (n−1)b< c , cấu hình chiến lược
' '
α =(α LDR , α FLR )=(init . r . ¬ report , collude . r . ¬report ) là Cân bằng Nash của Trò chơi 2. Với hồ
sơ chiến lược này, tất cả những người thực thi chọn thông đồng để báo cáo một kết quả giả r ' và
không báo cáo kết quả đó; cùng với Hợp đồng thuê ngoài thứ nhất, điều này dẫn đến một sự
thông đồng ác tính.

TỰ PHÂN TÍCH:
Khi tiền cọc của mỗi LDR, FLR lớn hơn tổng số tiền cọc thực thi của toàn bộ số người còn lại
trong cùng một HDSC và tiền hối lộ của LDR nhỏ hơn chi phí thực thi HDSC, thì số tiền cọc của
mỗi người tham gia thông đồng quá lớn khiến cho họ muốn chắc chắn rằng không được để mất
số tiền cọc của bản thân. Cùng với nhu cầu muốn tối ưu hoá lợi nhuận của bản thân nên mọi
người sẽ chọn tham gia vào thông đồng và với chiến lược α =(α LDR , α FLR ). Kết quả là họ thành
công trong việc triển khai thông đồng ác tính.

3) Tóm tắt: Dựa trên phân tích trên về các trò chơi được tạo ra từ Hợp đồng thuê ngoài thứ
nhất, đặc biệt là Bổ đề 1 và 2, chúng ta có Định lý 1 sau đây.

Định lý 1: Nếu chủ sở hữu HDSC tương tác với những người thực thi dựa trên Hợp đồng thuê
ngoài thứ nhất, hợp đồng này chỉ khởi chạy tính toán tin cậy một cách phản ứng khi những người
thực thi báo cáo các kết quả khác nhau hoặc báo cáo sự thông đồng, thì có khả năng những người
thực thi thành công trong một sự thông đồng ác tính.

D. Phân tích II: Hợp đồng thuê ngoài thứ hai v.s. thông đồng

Trong tiểu mục này, trước tiên chúng ta phân tích các trò chơi do hợp đồng thuê ngoài thứ hai
gây ra so với Thông đồng loại I và loại II tương ứng. Sau đó, chúng tôi tóm tắt phân tích và trình
bày kết luận của mình rằng, dựa trên hợp đồng thuê ngoài thứ hai chủ động khởi chạy một tính
toán tin cậy với xác suất phù hợp, những người thực thi sẽ không chọn thực hiện một sự thông
đồng ác tính, vì sự thông đồng đó sẽ không tối đa hóa các tiện ích của họ.

1) Hợp đồng thuê ngoài thứ hai v.s. Thông đồng Loại I: Hình 3 minh họa Trò chơi 3 do
hợp đồng thuê ngoài thứ hai và Thông đồng Loại I gây ra. Lưu ý rằng, chúng tôi bỏ qua các
nhánh có báo cáo thông đồng vì chiến lược báo cáo thông đồng bị chi phối bởi chiến lược kiểm
tra và gửi kết quả chính xác.

Hình 3: Trò chơi tạo ra bởi hợp đồng thuê ngoài thứ hai và hợp đồng Thông đồng Loại I. Các
tiện ích cho LDR và mỗi FLR trong mỗi hồ sơ chiến lược (nghĩa là trong mỗi nhánh) được
d LDR n1 d executor−c full
liệt kê như sau: u5 , L =−d executor −d LDR, u5 , F =w−c + + ,
n−1 n0
u7 , L =w−c +(n−1)d FLR , u7 , F =w−c −d FLR , u8 , L =u7 , L , u8 , F =u7 , F , u9 , L =u7 , L , u9 , F =w−d FLR,
d LDR
u10 , L =u7 , L, u10 , F =u9 , F , u11 , L=u5 , L, u11 , F=−d executor + , u13 , L =u5 , L, u13 , F =u11 ,F ,
n−1
u14 , L =w+(n−1)d FLR và u14 , F =w−d FLR.

Phân tích trò chơi, ta có bổ đề 3 sau. Theo trực quan, bổ đề chỉ ra rằng, khi chủ HDSC có xác
suất phù hợp để chủ động khởi động một phép tính toán tin cậy, thì trò chơi 3 sẽ không kết thúc
tại một hồ sơ chiến lược trong đó tất cả những người thực thi thông đồng nộp bài một kết quả
không chính xác và không báo cáo sự thông đồng. Do đó, trò chơi chỉ có thể kết thúc ở trạng thái
 không có thông đồng hoặc người thực thi báo cáo kết quả khác nhau hoặc một số người thực thi
báo cáo thông đồng; không có trường hợp nào làm cho kết quả sai được chấp nhận.

c
Bổ đề 3: Miễn là pfallback ≥ , trò chơi 3 sẽ không kết thúc ở trạng thái v13 hoặc v14 . Tức là
d executor
những người thực thi lý trí sẽ không cộng tác để tiến hành một sự thông đồng ác tính.

Mặc dù Bổ đề 3 ở trên cho thấy rằng có thể ngăn chặn được sự thông đồng loại I ác tính, nhưng
c
tần suất chủ động khởi chạy tính toán tin cậy cần phải là . Tuy nhiên, Hệ quả sau đây cho
d executor
thấy rằng, một sự thông đồng loại I có tính công bằng có thể được ngăn chặn thành ác tính với
tần suất thấp hơn và tần suất có thể mở rộng hơn để chủ động khởi chạy tính toán tin cậy. Lưu ý
rằng, thông đồng Loại I có tính công bằng hạn chế hơn so với thông đồng Loại I thông thường
bằng cách yêu cầu d LDR ≥(n−1)d executor ; nhưng như đã giải thích trong Phần IV-B1, yêu cầu bổ
sung này là hợp lý về mặt kinh tế trong thực tế để bảo vệ những người theo dõi trong hợp đồng
thông đồng chống lại một nhà lãnh đạo có hành vi sai trái, người không giữ lời hứa cung cấp một
kết quả chính xác.

Hệ quả 2: Đối với thông đồng Loại I có tính công bằng (nghĩa là d LDR ≥(n−1) d executor ), miễn là
c
pfallback ≥ , Trò chơi 3 sẽ không kết thúc ở trạng thái v13 hoặc v14 . Tức là những người
n d executor
thực thi lý trí sẽ không cộng tác để tiến hành một sự thông đồng ác tính.

p FLR 1− p FLR
LDR\FLR
r r'

pfallback 1− p fallback pfallback 1− p fallback

p LDR r
u7 , L =w−c +(n−1)d FLRuu87,,LF=w−c
=w−c−d
+(n−1)d
FLR FLR u98,,LF=w−c
=w−c−d
+(n−1)d
FLR FLR u 9, F =w−d
u10 , LFLR
=w−c +(n−1) d FLR u10 , F=w
n−2 n−2
d n d −c1−( 1− pFLR ) ( 1− p FLR )
1− p LDR r' u5 , L =−d exexecutor −d FLR u5 , F =w−c+ LDR + 1 executor full
n−1 n0
pfallback 1− p fallback
 d LDR
u11 , L=−d exexecutor−d LDR u11 , F=−d
u13exexecutor
, L =−d
u14FLR
+exexecutor −d , L =w+(n−
u13 , F =−d
n−1

TỰ PHÂN TÍCH:
Theo công thức bổ đề 3, ta có pfallback tỉ lệ thuận với c và tỉ lệ nghịch với d executor . Ta thấy tần
suất sử dụng biện pháp ngăn chặn tăng khi chi phí thực thi HDSC tăng. Lý giải cho điều này là
khi chi phí thực thi tăng thì sẽ làm giảm nhu cầu muốn thực thi tính toán HDSC của người tham
gia và khi đó họ mong muốn tham gia thông đồng. Khi tham gia thông đồng chắc chắn họ sẽ
không kiếm tra lại kết quả mà LDR cung cấp nên trò chơi có thể kết thúc ở trạng thái v13 hoặc v14
. Còn tần suất sử dụng biện pháp ngăn chặn tỉ lệ nghịch với tiền cọc thực thi HDSC vì khi tiền
cọc thực thi HDSC giảm thì khả năng người thực thi HDSC làm theo đúng với hợp đồng càng
thấp. Và do trong trường hợp thông đồng ác tính ở trên thu được lợi nhuận cao nhất nên khả
năng họ tham gia thông đồng ác tính càng cao.

Theo công thức hệ quả 2, ta thêm một chỉ số là pfallback tỉ lệ nghịch với n hay tần suất sử dụng
biện pháp ngăn chặn giảm khi số lượng người thực thi tăng. Có hai lí do cho việc này.Một là khi
d LDR ≥(n−1)d executor thì tiền cọc của LDR sẽ công bằng với mọi FLR. Điều đó khuyến khích FLR
tham gia thông đồng của LDR. Hai là khi số lượng người tăng lên thì càng khó để chắc chắn toàn
người thực thi tham gia thông đồng. Nên khi n tăng thì khả năng xảy ra thông đồng ác tính giảm
cùng với đó pfallback cũng giảm theo.

2) Hợp đồng thuê ngoài thứ hai v.s. Thông đồng Loại II: Hình 4 minh họa Trò chơi 4 do
hợp đồng thuê ngoài thứ hai và Thông đồng Loại II gây ra.

Phân tích trò chơi 4 ta có Bổ đề 4 như sau.

 c
Bổ đề 4: Miễn là pfallback ≥ , trò chơi thể hiện trong Hình 4 sẽ không kết thúc ở
( n−1 ) . d executor
trạng thái v15 hoặc v16 .

Lưu ý rằng, ở mỗi trạng thái đầu cuối khác với v16 , thông đồng loại II không được khởi chạy
hoặc không thành công (do các bên gửi kết quả khác nhau hoặc một số bên báo cáo thông đồng).
c
Do đó, theo Bổ đề 4, miễn là pfallback ≥ , thông đồng loại II không thể thành công.
( n−1 ) . d executor

p FLR 1− p FLR
LDR\FLR
r r'

pfallback 1− p fallback
p LDR r u8 , L =z−dl +b 1 u 8 ,F =−d e +b 5
u11 , L= z−d l +b1 u11 ,F =z−d
u12 , Lf =
+bz−d
1 l +b1 u12 ,F =z−d f +b 1

1−( 1− pFLR )n−2 ( 1− p FLR )

n−2

1− p LDR r' u9 , L =−d e +b 4 u 9 , F=z −d f + b1 pfallback 1− p fallback

u13 , L =−d e + b4 u13 , F =−d e +b6
u15 , L =−d e −d l uu1516, F,=−d e −d f
L =w−(n−1)

TỰ PHÂN TÍCH:
Sự khác biệt giữa pfallback của hai trò chơi là theo trò chơi 3 thì tỉ lệ nghịch với n còn ở trò chơi
4 này thì nó tỉ nghịch với n−1. Lí do cho vấn đề này là do sự khác nhau giữa hai thông đồng.
 3) Trường hợp đặc biệt: Khi tất cả những người thực thi được chọn có cùng quan tâm (ví
dụ: họ thuộc về cùng một thợ đào coin hoặc cùng một nhóm thợ), với Hợp đồng thuê ngoài thứ
hai, chúng ta có Bổ đề 5 sau đây.

Hình 4: Trò chơi tạo ra bởi hợp đồng thuê ngoài thứ hai và hợp đồng Thông đồng Loại II.
Các cạnh in đậm biểu thị các hành động mà người thực thi sẽ thực hiện ở trạng thái cân
bằng tuần tự duy nhất. Nút đầu cuối có thể truy cập của trò chơi có màu xám. Tiện ích của
LDR và FLR trong mỗi nhánh được liệt kê như sau. u8 , L =z−dl +b 1, u8 , F =−d e +b5 ,
u9 , L =−d e +b 4, u9 , F =z−d f +b1 , u11 , L=u8 , L, u11 , F=u9 , F, u12 , L=u8 , L, u12 , F=u9 , F, u13 , L =−d e + b4 ,
u13 , F =−d e + b6, u15 , L =−d e −d l , u15 , F =−d e −d f , u16 , L =w−( n−1 ) b , và u16 , F =w+ b.
 c
Bổ đề 5: Miễn là pfallback ≥ , chiến lược tốt nhất cho tất cả những người thực thi có
( n−1 ) . d executor
cùng mối quan tâm là có một người thực thi kết quả tính toán trung thực và tất cả những người
thực thi đã gửi kết quả được tính toán và nhận phần thưởng n . w−c theo nhóm.

4) Tóm tắt: Dựa trên phân tích ở trên về các trò chơi được tạo ra từ hợp đồng thuê ngoài thứ
hai và thông đồng Loại I hoặc thông đồng Loại II có tính công bằng, đặc biệt là Hệ quả 2, Bổ đề
4 và Bổ đề 5, chúng ta có Định lý 3 sau đây.

Định lý 3: Nếu chủ sở hữu HDSC tương tác với người thực thi dựa trên hợp đồng thuê ngoài
thứ hai và sự thông đồng tiềm ẩn của người thực thi là thông đồng Loại I có tính công bằng hoặc
thông đồng Loại II, thì người thực thi hợp lý về mặt kinh tế sẽ không thực hiện hành vi thông
c
đồng ác tính miễn là pfallback ≥ trong hợp đồng thuê ngoài thứ hai.
( n−1 ) . d executor

V. THỰC NGHIỆM VÀ ĐÁNH GIÁ

Như chứng minh cho ý tưởng, chúng tôi triển khai hệ thống được đề xuất trên Ethereum. Cụ
thể, chúng tôi triển khai trong Solidity một mẫu HDSC như được trình bày trong Phần III và hợp
đồng thuê ngoài thứ hai được đề xuất trong Phần IV; chúng tôi phát triển trong Javascript một
chương trình có thể được gọi bởi Geth - triển khai Go chính thức của Ethereum để xử lý các
HDSC theo cách mà chúng tôi đề xuất.

Để kiểm tra và đánh giá hệ thống, chúng tôi thuê các phiên bản AWS EC2, mỗi phiên bản chạy
Ubuntu Server 18.04 LTS với RAM 8GB, để thiết lập mạng Ethereum riêng quy mô nhỏ với tối
đa 32 nút. Mỗi HDSC chứa mã áp dụng hàm băm Kaccak-256 trên một chuỗi trong 1000 lần; để
đơn giản, không cần đầu vào. Các biến trong đánh giá bao gồm: (i) N : tổng số nút đầy đủ; N
thay đổi từ 8 đến 32, với 32 là giá trị mặc định. (ii) n : số lượng người thực thi mỗi HDSC; n thay
đổi từ 6 đến 12 với 6 là giá trị mặc định. (iii) α : số khối cần thiết phải mở rộng tuyến tính một
khối trước khi khối đó được coi là ổn định; trong đánh giá này, chúng tôi đặt α =n . (iv) ρ : số
lượng HDSC phát hành mỗi phút, thay đổi từ 1 đến 4 với giá trị mặc định là 2.
 Chúng tôi đo lường các chỉ số hiệu suất sau: (i) getResDelay: độ trễ từ khi HDSC sẵn sàng cho
đến khi thu được kết quả chính xác. (ii) finalizeDelay: độ trễ từ khi HSDC sẵn sàng cho đến khi
HDSC được xử lý xong.

Kết quả được trình bày trong Hình 5, trong đó mỗi điểm là giá trị trung bình của các phép đo
được thu thập trong một giờ và khoảng tin cậy 95% được mô tả dưới dạng các đường thẳng
đứng.

Như được hiển thị trong Hình 5(a), khi N=32, ρ=2 và n=α =6 , độ trễ trung bình từ khi
HDSC sẵn sàng cho đến khi có kết quả thực thi là khoảng 250 giây, có thể được giải thích là như
sau: Giả sử một HDSC sẵn sàng ở khối x , những người thực thi nó là những người khai thác khối
x +1; x +2 ; ...; x +6 . Khối x +6 chỉ ổn định sau khối x +7 ; ...; x +12 đã được thêm vào (do α =6 ),
đây là thời điểm mà tất cả những người thực thi có thể bắt đầu thực thi mã HDSC. Sau khi quá
trình thực thi kết thúc, các cam kết được đăng lên các khối sau, các cam kết này chỉ ổn định sau
khi chúng được mở rộng tuyến tính thêm ít nhất α =6 khối nữa. Sau đó, những người thực thi có
thể bắt đầu tiết lộ kết quả của họ cho các khối sau, các khối này cũng ổn định sau khi được mở
rộng tuyến tính thêm ít nhất α =6 khối. Do đó, kết quả không thể được tiết lộ trước khối x +24 .
Vì khoảng thời gian của khối thường là từ 10 đến 20 giây, độ trễ từ khi HDSC sẵn sàng cho đến
khi kết quả thực thi được tiết lộ là hơn 200 giây. Sau khi kết quả được tiết lộ, cần thêm 100 giây
nữa để việc phân phối tiền cọc được thực hiện và ổn định. Kết quả này chỉ ra rằng, khi tần suất
đăng HDSC lên blockchain không cao và mỗi HDSC không yêu cầu số lượng người thực thi lớn,
thì độ trễ chủ yếu là do: (i) độ trễ để chờ khối ổn định, (ii) độ trễ cho xác định người thực thi và
(iii) một số bước (nghĩa là bước cam kết kết quả và bước tiết lộ kết quả) theo yêu cầu của kế
hoạch đề xuất. Ở đây, các yếu tố (ii) và (iii) là tổng chi phí do sơ đồ đề xuất đưa ra và cũng là sự
đánh đổi để không liên quan đến tất cả các nút trong quá trình thực thi.

Hình 5(a) cũng cho thấy độ trễ thay đổi như thế nào theo n . Như mong đợi, khi n tăng (đồng
thời tăng α ), độ trễ cũng tăng tương ứng. Hơn nữa, khi n tăng lên, tỷ lệ phần trăm nút lớn hơn (từ
19% đến 38%) được yêu cầu cho mỗi lần thực thi HDSC, dẫn đến độ trễ tăng mạnh. Hiện tượng
này chỉ ra rằng, khi tỷ lệ phần trăm nút lớn hơn được yêu cầu để thực thi HDSC, thì không chỉ
lãng phí nhiều năng lượng tính toán hơn mà còn phát sinh độ trễ lâu hơn do khối lượng công việc
tăng lên của mỗi nút làm giảm thông lượng hệ thống. Điều này cũng được lặp lại bởi Hình 5(b)
cho thấy rằng, khi n=6, N càng lớn (tức là tỷ lệ phần trăm nút mạng được yêu cầu để thực thi
HDSC càng nhỏ) thì độ trễ càng ngắn.

Hình 5: Độ trễ với số lượng của người thực thi, nút và các HDSC mỗi phút.

Hình 5(c) cho thấy sự thay đổi độ trễ với ρ , trong đó 19% (tức là 6 trong số 32) nút được yêu
cầu thực thi từng HDSC. Như chúng ta có thể thấy, khi ρ tăng (tức là, nhiều HDSC được phát
hành mỗi phút, khối lượng công việc được thực hiện bởi mỗi nút cũng tăng lên, điều này gây ra
sự chậm trễ tăng mạnh. Điều này càng cho thấy sự cần thiết phải giảm tỷ lệ phần trăm các nút
cần thiết để thực hiện từng nút HDSC, đặc biệt là khi số lượng HDSC cấp cho hệ thống trở nên
lớn.

VI. Kết luận và định hướng trong tương lai

Bài báo này đã đề xuất một giải pháp thực tế, dựa trên lý thuyết trò chơi, để thực hiện hiệu quả
và an toàn các hợp đồng thông minh lớn. Phân tích lý thuyết trò chơi mở rộng đã được tiến hành
để chỉ ra tính bảo mật và hiệu quả tính toán của giải pháp, ngay cả khi đối mặt với sự thông đồng
giữa những người thực thi. Giải pháp đề xuất đã được triển khai trên Ethereum và được thử
nghiệm trong một mạng riêng quy mô nhỏ, để chứng minh tính thực tế và khả năng tương thích
của nó với Ethereum. Trong tương lai, chúng tôi có kế hoạch tăng cường triển khai hiện tại và
tiến hành các thử nghiệm quy mô lớn hơn để đánh giá thêm giải pháp.