Cuộc tranh chấp hợp đồng thông minh: Hyperledger Fabric vs MultiChain vs Ethereum vs Corda

Có nhiều cách để đặt mã trên blockchain

Trong hầu hết các cuộc thảo luận về blockchain, không mất nhiều thời gian để đưa ra khái niệm về "hợp đồng thông minh". Trong trí tưởng tượng phổ biến, hợp đồng thông minh tự động hóa việc thực hiện các tương tác giữa các bên mà không yêu cầu trung gian đáng tin cậy. Bằng cách thể hiện các mối quan hệ pháp lý bằng mã chứ không phải từ ngữ, họ hứa hẹn sẽ cho phép các giao dịch diễn ra trực tiếp và không có sai sót, cho dù có cố ý hay không.

Từ quan điểm kỹ thuật, hợp đồng thông minh là một cái gì đó cụ thể hơn: mã máy tính sống trên một chuỗi khối và xác định các quy tắc cho các giao dịch của chuỗi đó. Mô tả này nghe có vẻ đơn giản, nhưng đằng sau nó ẩn chứa rất nhiều sự thay đổi trong cách các quy tắc này được thể hiện, thực thi và xác thực. Khi chọn một nền tảng blockchain cho một ứng dụng mới, câu hỏi "Nền tảng này có hỗ trợ các hợp đồng thông minh không?" không phải là người thích hợp để hỏi. Thay vào đó, chúng ta cần hỏi: "Nền tảng này hỗ trợ loại hợp đồng thông minh nào?"

Trong bài viết này, mục tiêu của tôi là kiểm tra một số khác biệt chính giữa các phương pháp tiếp cận hợp đồng thông minh và sự đánh đổi mà chúng đại diện. Tôi sẽ làm điều này bằng cách xem xét bốn nền tảng blockchain doanh nghiệp phổ biến hỗ trợ một số dạng mã trên chuỗi tùy chỉnh. Đầu tiên, IBM's Vải Hyperledger, gọi các hợp đồng của nó là "chaincode". Thứ hai, nền tảng MultiChain của chúng tôi, giới thiệu bộ lọc thông minh trong phiên bản 2.0. Ngày thứ ba, Ethereum (và nó được phép Quorum và Hang thỏ spin-off), phổ biến tên “hợp đồng thông minh”. Và cuối cùng, R3 Corda, tham chiếu đến "hợp đồng" trong các giao dịch của nó. Mặc dù tất cả các thuật ngữ khác nhau, nhưng cuối cùng tất cả chúng đều đề cập đến cùng một thứ - mã dành riêng cho ứng dụng xác định các quy tắc của một chuỗi.

Trước khi đi xa hơn, tôi nên cảnh báo người đọc rằng phần lớn nội dung sau đây mang tính chất kỹ thuật và giả sử một số quen thuộc với các khái niệm cơ sở dữ liệu và lập trình chung. Dù tốt hay xấu, điều này không thể tránh khỏi - nếu không đi sâu vào chi tiết thì không thể đưa ra quyết định sáng suốt về việc có nên sử dụng blockchain cho một dự án cụ thể hay không và (nếu có) loại blockchain phù hợp để sử dụng.

Khái niệm cơ bản về chuỗi khối

Hãy bắt đầu với một số ngữ cảnh. Hãy tưởng tượng một ứng dụng được chia sẻ bởi nhiều tổ chức, dựa trên cơ sở dữ liệu cơ bản. Trong kiến ​​trúc tập trung truyền thống, cơ sở dữ liệu này được lưu trữ và quản lý bởi một bên duy nhất mà tất cả những người tham gia đều tin tưởng, ngay cả khi họ không tin tưởng lẫn nhau. Các giao dịch sửa đổi cơ sở dữ liệu chỉ được khởi tạo bởi các ứng dụng trên hệ thống của bên trung tâm này, thường là để phản hồi các thông báo nhận được từ những người tham gia. Cơ sở dữ liệu chỉ đơn giản thực hiện những gì nó được yêu cầu bởi vì ứng dụng được ngầm tin tưởng để chỉ gửi cho nó các giao dịch có ý nghĩa.

Blockchains cung cấp một cách thay thế để quản lý cơ sở dữ liệu được chia sẻ mà không cần trung gian đáng tin cậy. Trong một chuỗi khối, mỗi người tham gia chạy một "nút" chứa một bản sao của cơ sở dữ liệu và xử lý độc lập các giao dịch sửa đổi nó. Những người tham gia được xác định bằng cách sử dụng khóa công khai hoặc “địa chỉ”, mỗi khóa có một khóa riêng tương ứng mà chỉ chủ sở hữu danh tính mới biết. Mặc dù các giao dịch có thể được tạo bởi bất kỳ nút nào, nhưng chúng được “ký điện tử” bằng khóa riêng của người khởi tạo để chứng minh nguồn gốc của chúng.

Các nút kết nối với nhau theo kiểu ngang hàng, truyền bá nhanh chóng các giao dịch và các “khối” trong đó chúng được đánh dấu thời gian và xác nhận trên toàn mạng. Bản thân blockchain theo nghĩa đen là một chuỗi các khối này, tạo thành một bản ghi có thứ tự của mọi giao dịch lịch sử. Một "thuật toán đồng thuận" được sử dụng để đảm bảo rằng tất cả các nút đạt được thỏa thuận về nội dung của blockchain mà không yêu cầu kiểm soát tập trung. (Lưu ý rằng một số mô tả này không áp dụng cho Corda, trong đó mỗi nút chỉ có một bản sao cơ sở dữ liệu một phần và không có chuỗi khối toàn cầu. Chúng ta sẽ nói thêm về điều đó sau).

Về nguyên tắc, bất kỳ ứng dụng cơ sở dữ liệu được chia sẻ nào đều có thể được kiến ​​trúc bằng cách sử dụng một chuỗi khối ở cốt lõi của nó. Nhưng làm như vậy sẽ tạo ra một số thách thức kỹ thuật không tồn tại trong kịch bản tập trung:

• Quy tắc giao dịch. Nếu bất kỳ người tham gia nào có thể trực tiếp thay đổi cơ sở dữ liệu, làm thế nào để chúng tôi đảm bảo rằng họ tuân theo các quy tắc của ứng dụng? Điều gì ngăn một người dùng làm hỏng nội dung của cơ sở dữ liệu theo cách tự phục vụ?
• Thuyết định mạng. Khi các quy tắc này được xác định, chúng sẽ được nhiều nút áp dụng nhiều lần khi xử lý các giao dịch cho bản sao cơ sở dữ liệu của chính chúng. Làm cách nào để chúng tôi đảm bảo rằng mọi nút đều nhận được chính xác cùng một kết quả?
• Phòng ngừa xung đột. Nếu không có sự điều phối trung tâm, làm thế nào để chúng ta xử lý hai giao dịch mà mỗi giao dịch đều tuân theo các quy tắc của ứng dụng, nhưng vẫn xung đột với nhau? Xung đột có thể bắt nguồn từ một nỗ lực cố ý để chơi trò chơi của hệ thống, hoặc là kết quả vô tội của vận rủi và thời gian.

Vậy hợp đồng thông minh, bộ lọc thông minh và chaincode đi vào đâu? Mục đích cốt lõi của họ là làm việc với cơ sở hạ tầng cơ bản của blockchain để giải quyết những thách thức này. Hợp đồng thông minh là mã ứng dụng tương đương phi tập trung - thay vì chạy ở một nơi trung tâm, chúng chạy trên nhiều nút trong chuỗi khối, tạo hoặc xác thực các giao dịch sửa đổi nội dung của cơ sở dữ liệu đó.

Hãy bắt đầu với các quy tắc giao dịch, thách thức đầu tiên trong số những thách thức này và xem chúng được thể hiện như thế nào trong Fabric, MultiChain, Ethereum và Corda tương ứng.

Quy tắc giao dịch

Các quy tắc giao dịch thực hiện một chức năng cụ thể trong cơ sở dữ liệu được hỗ trợ bởi blockchain - hạn chế biến đổi có thể được thực hiện trên trạng thái của cơ sở dữ liệu đó. Điều này là cần thiết vì các giao dịch của blockchain có thể được bắt đầu bởi bất kỳ người tham gia nào và những người tham gia này không đủ tin tưởng lẫn nhau để cho phép họ sửa đổi cơ sở dữ liệu theo ý muốn.

Hãy xem hai ví dụ về lý do tại sao các quy tắc giao dịch là cần thiết. Đầu tiên, hãy tưởng tượng một blockchain được thiết kế để tổng hợp và đánh dấu thời gian các tài liệu PDF được xuất bản bởi những người tham gia. Trong trường hợp này, không ai có quyền xóa hoặc thay đổi tài liệu, vì làm như vậy sẽ làm suy yếu toàn bộ mục đích của hệ thống - tính bền vững của tài liệu. Thứ hai, hãy xem xét một blockchain đại diện cho một sổ cái tài chính được chia sẻ, theo dõi số dư của người dùng. Chúng tôi không thể cho phép người tham gia tự ý tăng số dư của họ hoặc lấy tiền của người khác.

Đầu vào và đầu ra

Các nền tảng blockchain của chúng tôi dựa trên hai cách tiếp cận rộng rãi để thể hiện các quy tắc giao dịch. Đầu tiên, tôi gọi là "mô hình đầu vào-đầu ra", được sử dụng trong MultiChain và Corda. Ở đây, các giao dịch liệt kê rõ ràng các hàng hoặc “trạng thái” của cơ sở dữ liệu mà chúng xóa và tạo, tạo thành một tập hợp các “đầu vào” và “đầu ra” tương ứng. Việc sửa đổi một hàng được biểu thị bằng thao tác tương đương với việc xóa hàng đó và tạo một hàng mới vào vị trí của nó.

Vì các hàng cơ sở dữ liệu chỉ bị xóa trong đầu vào và chỉ được tạo trong đầu ra, mọi đầu vào phải “tiêu” đầu ra của giao dịch trước đó. Trạng thái hiện tại của cơ sở dữ liệu được định nghĩa là tập hợp “đầu ra giao dịch chưa sử dụng” hoặc “UTXO”, tức là đầu ra từ các giao dịch trước đó chưa được sử dụng. Các giao dịch cũng có thể chứa thông tin bổ sung, được gọi là “siêu dữ liệu”, “lệnh” hoặc “tệp đính kèm”, không trở thành một phần của cơ sở dữ liệu nhưng giúp xác định ý nghĩa hoặc mục đích của chúng.

Với ba bộ đầu vào, đầu ra và siêu dữ liệu này, tính hợp lệ của giao dịch trong MultiChain hoặc Corda được xác định bởi một số mã có thể thực hiện các phép tính tùy ý trên các bộ đó. Mã này có thể xác thực giao dịch, nếu không sẽ trả về lỗi kèm theo lời giải thích tương ứng. Bạn có thể coi mô hình đầu vào - đầu ra như một “người kiểm tra” tự động nắm giữ một danh sách kiểm tra để đảm bảo rằng các giao dịch tuân theo từng quy tắc. Nếu giao dịch không thành công bất kỳ một trong những lần kiểm tra đó, nó sẽ tự động bị từ chối bởi tất cả các nút trong mạng.

Cần lưu ý rằng, mặc dù chia sẻ mô hình đầu vào - đầu ra, MultiChain và Corda thực hiện nó rất khác nhau. Trong MultiChain, đầu ra có thể chứa nội dung và / hoặc dữ liệu ở định dạng JSON, văn bản hoặc nhị phân. Các quy tắc được xác định trong "bộ lọc giao dịch" hoặc "bộ lọc luồng", có thể được đặt để kiểm tra tất cả các giao dịch hoặc chỉ những giao dịch liên quan đến nội dung hoặc nhóm dữ liệu cụ thể. Ngược lại, “trạng thái” đầu ra Corda được biểu diễn bằng một đối tượng trong ngôn ngữ lập trình Java hoặc Kotlin, với các trường dữ liệu được xác định. Các quy tắc của Corda được định nghĩa trong “hợp đồng” được gắn với các tiểu bang cụ thể và hợp đồng của tiểu bang chỉ được áp dụng cho các giao dịch có trạng thái đó trong đầu vào hoặc đầu ra của nó. Điều này liên quan đến Corda mô hình khả năng hiển thị bất thường, trong đó các giao dịch chỉ có thể được nhìn thấy bởi các đối tác của họ hoặc những người có ảnh hưởng đến các giao dịch tiếp theo của họ.

Hợp đồng và tin nhắn

Cách tiếp cận thứ hai, mà tôi gọi là “mô hình hợp đồng-tin nhắn”, được sử dụng trong Hyperledger Fabric và Ethereum. Tại đây, nhiều “hợp đồng thông minh” hoặc “mã mã hóa” có thể được tạo trên blockchain và mỗi loại có cơ sở dữ liệu riêng và mã liên quan. Cơ sở dữ liệu của một hợp đồng chỉ có thể được sửa đổi bằng mã của nó, thay vì trực tiếp bằng các giao dịch blockchain. Mẫu thiết kế này tương tự như “đóng gói” mã và dữ liệu trong lập trình hướng đối tượng.

Với mô hình này, một giao dịch blockchain bắt đầu dưới dạng một thông điệp được gửi đến một hợp đồng, với một số thông số hoặc dữ liệu tùy chọn. Mã của hợp đồng được thực thi theo phản ứng với thông báo và các tham số, đồng thời có thể tự do đọc và ghi cơ sở dữ liệu của chính nó như một phần của phản ứng đó. Các hợp đồng cũng có thể gửi tin nhắn đến các hợp đồng khác, nhưng không thể truy cập trực tiếp vào cơ sở dữ liệu của nhau. Trong ngôn ngữ của cơ sở dữ liệu quan hệ, hợp đồng hoạt động như thi hành "Các thủ tục được lưu trữ", nơi tất cả các quyền truy cập vào cơ sở dữ liệu đều thông qua một số mã xác định trước.

Cả Fabric và Quorum, một biến thể của Ethereum, làm phức tạp bức tranh này bằng cách cho phép một mạng xác định nhiều "kênh" hoặc "trạng thái riêng tư". Mục đích là để giảm thiểu vấn đề bảo mật blockchain bằng cách tạo ra các môi trường riêng biệt, mỗi môi trường chỉ hiển thị cho một nhóm nhỏ người tham gia cụ thể. Mặc dù điều này nghe có vẻ hứa hẹn về mặt lý thuyết, nhưng trên thực tế, các hợp đồng và dữ liệu trong mỗi kênh hoặc trạng thái riêng tư bị cô lập với những hợp đồng và dữ liệu trong những kênh khác. Do đó, về mặt hợp đồng thông minh, các môi trường này tương đương với các blockchain riêng biệt.

Quy tắc mẫu

Hãy xem cách thực hiện các quy tắc giao dịch cho sổ cái tài chính một tài sản với hai mô hình này. Mỗi hàng trong cơ sở dữ liệu sổ cái của chúng tôi có hai cột, chứa địa chỉ của chủ sở hữu và số lượng tài sản sở hữu. Trong mô hình đầu vào - đầu ra, các giao dịch phải thỏa mãn hai điều kiện:

1. Tổng số lượng tài sản trong đầu ra của một giao dịch phải khớp với tổng số đầu vào của nó. Điều này ngăn không cho người dùng tạo hoặc xóa tiền một cách tùy tiện.
2. Mỗi giao dịch phải được ký bởi chủ sở hữu của mỗi đầu vào của nó. Điều này ngăn người dùng tiêu tiền của nhau mà không được phép.

Tổng hợp lại, hai điều kiện này là tất cả những gì cần thiết để tạo ra một hệ thống tài chính đơn giản nhưng khả thi.

Trong mô hình hợp đồng - tin nhắn, hợp đồng của nội dung hỗ trợ thông báo “gửi thanh toán”, có ba tham số: địa chỉ người gửi, địa chỉ người nhận và số lượng được gửi. Đáp lại, hợp đồng thực hiện bốn bước sau:

1. Xác minh rằng giao dịch đã được ký bởi người gửi.
2. Kiểm tra xem người gửi có đủ tiền hay không.
3. Khấu trừ số lượng yêu cầu từ hàng của người gửi.
4. Thêm số lượng đó vào hàng của người nhận.

Nếu một trong hai lần kiểm tra trong hai bước đầu tiên không thành công, hợp đồng sẽ bị hủy bỏ và không có khoản thanh toán nào được thực hiện.

Vì vậy, cả mô hình đầu vào - đầu ra và hợp đồng - thông điệp đều là những cách hiệu quả để xác định các quy tắc giao dịch và giữ an toàn cho cơ sở dữ liệu dùng chung. Thật vậy, trên mức lý thuyết, mỗi mô hình này có thể được sử dụng để mô phỏng mô hình kia. Tuy nhiên, trên thực tế, mô hình phù hợp nhất sẽ phụ thuộc vào ứng dụng đang được xây dựng. Mỗi giao dịch có ảnh hưởng đến ít hay nhiều thông tin? Chúng ta có cần đảm bảo tính độc lập của giao dịch không? Mỗi phần dữ liệu có chủ sở hữu rõ ràng hay có một số trạng thái toàn cầu được chia sẻ?

Ở đây nằm ngoài phạm vi của chúng tôi để khám phá cách các câu trả lời sẽ ảnh hưởng đến sự lựa chọn giữa hai mô hình này. Nhưng theo hướng dẫn chung, khi phát triển một ứng dụng blockchain mới, bạn nên cố gắng thể hiện các quy tắc giao dịch của nó ở cả hai dạng và xem cái nào phù hợp một cách tự nhiên hơn. Sự khác biệt sẽ thể hiện ở khía cạnh: (a) dễ lập trình, (b) yêu cầu lưu trữ và thông lượng, và (c) tốc độ phát hiện xung đột. Chúng ta sẽ nói thêm về vấn đề cuối cùng này ở phần sau.

Quy tắc tích hợp

Khi nói đến các quy tắc giao dịch, có một cách mà MultiChain đặc biệt khác với Fabric, Ethereum và Corda. Không giống như các nền tảng khác này, MultiChain có một số bản tóm tắt tích hợp cung cấp một số khối xây dựng cơ bản cho các ứng dụng theo hướng blockchain, không có Yêu cầu các nhà phát triển để viết mã của riêng họ. Những phần tóm tắt này bao gồm ba lĩnh vực thường cần thiết: (a) quyền động, (b) nội dung có thể chuyển và (c) lưu trữ dữ liệu.

Ví dụ: MultiChain quản lý các quyền kết nối với mạng, gửi và nhận các giao dịch, tạo nội dung hoặc luồng hoặc kiểm soát quyền của những người dùng khác. Nhiều tài sản có thể thay thế có thể được phát hành, chuyển nhượng, nghỉ hưu hoặc trao đổi một cách an toàn và nguyên tử. Bất kỳ số lượng “luồng” nào đều có thể được tạo trên một chuỗi để xuất bản, lập chỉ mục và truy xuất dữ liệu trên chuỗi hoặc ngoài chuỗi ở định dạng JSON, văn bản hoặc nhị phân. Tất cả các quy tắc giao dịch cho những nội dung trừu tượng này đều có sẵn.

Khi phát triển ứng dụng trên MultiChain, có thể bỏ qua chức năng tích hợp này và chỉ diễn đạt các quy tắc giao dịch bằng cách sử dụng bộ lọc thông minh. Tuy nhiên, các bộ lọc thông minh được thiết kế để hoạt động cùng với các phần tóm tắt tích hợp của nó, bằng cách cho phép hành vi mặc định của chúng hạn chế theo những cách tùy chỉnh. Ví dụ: quyền cho các hoạt động nhất định có thể được kiểm soát bởi các quản trị viên cụ thể, thay vì hành vi mặc định mà bất kỳ quản trị viên nào sẽ làm. Việc chuyển nhượng các tài sản nhất định có thể bị giới hạn bởi thời gian hoặc yêu cầu sự chấp thuận bổ sung trên một số tiền nhất định. Dữ liệu trong một luồng cụ thể có thể được xác thực để đảm bảo rằng nó chỉ bao gồm các cấu trúc JSON với các trường và giá trị bắt buộc.

Trong tất cả các trường hợp này, bộ lọc thông minh tạo ra các yêu cầu bổ sung để các giao dịch được xác thực, nhưng không tẩy các quy tắc đơn giản được tích hợp sẵn. Điều này có thể giúp giải quyết một trong những thách thức chính trong các ứng dụng blockchain: thực tế là một lỗi trong một số mã trên chuỗi có thể dẫn đến hậu quả tai hại. Chúng tôi đã thấy vô số ví dụ về vấn đề này trong chuỗi khối Ethereum công khai, nổi tiếng nhất trong Sự sụp đổ của DAO và Lỗi đa chữ ký chẵn lẻ. Các cuộc khảo sát rộng hơn đã tìm thấy một số lượng lớn các lỗ hổng phổ biến trong các hợp đồng thông minh Ethereum cho phép những kẻ tấn công đánh cắp hoặc đóng băng tiền của những người khác.

Tất nhiên, bộ lọc thông minh MultiChain cũng có thể chứa lỗi, nhưng hậu quả của chúng bị hạn chế hơn về phạm vi. Ví dụ: các quy tắc tài sản tích hợp ngăn người dùng tiêu tiền của người khác hoặc vô tình làm cho tiền của họ biến mất, bất kể bộ lọc thông minh chứa logic nào khác. Nếu một lỗi được tìm thấy trong bộ lọc thông minh, nó có thể bị vô hiệu hóa và thay thế bằng một phiên bản đã sửa, trong khi tính toàn vẹn cơ bản của sổ cái được bảo vệ. Về mặt triết học, MultiChain gần với các kiến ​​trúc cơ sở dữ liệu truyền thống, nơi nền tảng cơ sở dữ liệu cung cấp một số trừu tượng dựng sẵn, chẳng hạn như cột, bảng, chỉ mục và các ràng buộc. Các tính năng mạnh mẽ hơn như trình kích hoạt và quy trình được lưu trữ có thể được các nhà phát triển ứng dụng tùy chọn mã hóa, trong những trường hợp chúng thực sự cần thiết.

Quy tắc giao dịch	vải	Đa chuỗi	Ethereum	Corda
Mô hình	Hợp đồng – tin nhắn	Đầu ra đầu vào	Hợp đồng – tin nhắn	Đầu ra đầu vào
Tích hợp	Không áp dụng	Quyền + nội dung + luồng	Không áp dụng	Không áp dụng

Thuyết định mạng

Hãy chuyển sang phần tiếp theo của cuộc thách đấu của chúng ta. Bất kể chúng tôi chọn cách tiếp cận nào, các quy tắc giao dịch tùy chỉnh của ứng dụng blockchain được thể hiện dưới dạng mã máy tính được viết bởi các nhà phát triển ứng dụng. Và không giống như các ứng dụng tập trung, mã này sẽ được thực thi nhiều lần và ở nhiều nơi cho mỗi giao dịch. Điều này là do nhiều nút blockchain thuộc về những người tham gia khác nhau phải xác minh và / hoặc thực hiện giao dịch đó cho chính họ.

Việc thực thi mã lặp đi lặp lại và dư thừa này giới thiệu một yêu cầu mới hiếm khi có trong các ứng dụng tập trung: thuyết xác định. Trong ngữ cảnh tính toán, thuyết xác định nghĩa là một đoạn mã sẽ luôn đưa ra cùng một câu trả lời cho các tham số giống nhau, bất kể nó được chạy ở đâu và khi nào. Điều này hoàn toàn quan trọng đối với mã tương tác với blockchain bởi vì, nếu không có tính xác định, sự đồng thuận giữa các nút trên chuỗi đó có thể bị phá vỡ một cách thảm khốc.

Hãy xem điều này trông như thế nào trong thực tế, trước tiên trong mô hình đầu vào - đầu ra. Nếu hai nút có ý kiến ​​khác nhau về việc liệu một giao dịch có hợp lệ hay không, thì một nút sẽ chấp nhận một khối chứa giao dịch đó còn nút kia thì không. Vì mọi khối liên kết rõ ràng trở lại khối trước đó, điều này sẽ tạo ra một "ngã ba" vĩnh viễn trong mạng, với một hoặc nhiều nút không chấp nhận ý kiến ​​của đa số về toàn bộ nội dung của blockchain kể từ thời điểm đó. Các nút trong nhóm thiểu số sẽ bị cắt khỏi trạng thái phát triển của cơ sở dữ liệu và sẽ không thể sử dụng ứng dụng một cách hiệu quả nữa.

Bây giờ, hãy xem điều gì sẽ xảy ra nếu sự đồng thuận bị phá vỡ trong mô hình hợp đồng - thông điệp. Nếu hai nút có ý kiến ​​khác nhau về cách hợp đồng sẽ phản hồi một thông báo cụ thể, điều này có thể dẫn đến sự khác biệt trong nội dung cơ sở dữ liệu của chúng. Điều này đến lượt nó có thể ảnh hưởng đến phản ứng của hợp đồng đối với các tin nhắn trong tương lai, bao gồm cả các tin nhắn mà nó gửi đến các hợp đồng khác. Kết quả cuối cùng là sự khác biệt ngày càng tăng giữa chế độ xem của các nút khác nhau về trạng thái của cơ sở dữ liệu. (Trường “gốc trạng thái” trong các khối Ethereum đảm bảo rằng bất kỳ sự khác biệt nào trong phản ứng của các hợp đồng đều dẫn đến ngay lập tức một đợt fork blockchain thảm khốc, thay vì mạo hiểm ở ẩn trong một khoảng thời gian.)

Các nguồn không xác định

Vì vậy, tính không xác định trong mã blockchain rõ ràng là một vấn đề. Nhưng nếu các khối cơ bản của tính toán, chẳng hạn như số học, là xác định, thì chúng ta phải lo lắng về điều gì? Chà, hóa ra, có khá nhiều thứ:

• Rõ ràng nhất, các bộ tạo số ngẫu nhiên, vì theo định nghĩa, chúng được thiết kế để tạo ra một kết quả khác nhau mỗi lần.
• Kiểm tra thời gian hiện tại, vì các nút sẽ không xử lý các giao dịch cùng một lúc và trong mọi trường hợp đồng hồ của chúng có thể không đồng bộ. (Vẫn có thể triển khai các quy tắc phụ thuộc vào thời gian bằng cách tham chiếu đến các dấu thời gian trong chính blockchain.)
• Truy vấn các tài nguyên bên ngoài như Internet, tệp đĩa hoặc các chương trình khác đang chạy trên máy tính. Các tài nguyên này không thể được đảm bảo luôn đưa ra cùng một phản hồi và có thể không có sẵn.
• Chạy nhiều đoạn mã trong các “luồng” song song, vì điều này dẫn đến “tình trạng cuộc đua” trong đó không thể dự đoán được thứ tự kết thúc của các quá trình này.
• Thực hiện bất kỳ phép tính dấu phẩy động nào có thể đưa ra các câu trả lời thậm chí rất khác nhau trên các kiến ​​trúc bộ xử lý máy tính khác nhau.

Bốn nền tảng blockchain của chúng tôi sử dụng một số cách tiếp cận khác nhau để tránh những cạm bẫy này.

Thực thi xác định

Hãy bắt đầu với Ethereum, vì cách tiếp cận của nó là “thuần túy” nhất. Các hợp đồng Ethereum được thể hiện ở một định dạng có mục đích đặc biệt gọi là “Ethereum bytecode”, được thực thi bởi Máy ảo Ethereum (“EVM”). Các lập trình viên không viết bytecode trực tiếp, mà tạo hoặc “biên dịch” nó từ một ngôn ngữ lập trình giống JavaScript được gọi là Solidity. (Các ngôn ngữ khác từng có sẵn nhưng kể từ đó đã không còn được dùng nữa.) Tính xác định được đảm bảo bởi thực tế là Solidity và Ethereum bytecode không thể mã hóa bất kỳ hoạt động không xác định nào - thật đơn giản.

Bộ lọc MultiChain và hợp đồng Corda chọn một cách tiếp cận khác, bằng cách điều chỉnh các ngôn ngữ lập trình và môi trường thời gian chạy hiện có. MultiChain sử dụng JavaScript chạy trong Google V8 engine, cũng tạo nên cốt lõi của trình duyệt Chrome và nền tảng Node.js, nhưng bị vô hiệu hóa các nguồn không xác định. Tương tự, Corda sử dụng Java hoặc Kotlin, cả hai đều được biên dịch thành “Java bytecode” thực thi trong Máy ảo Java (“JVM”). Hiện tại, Corda sử dụng JVM không xác định tiêu chuẩn của Oracle, nhưng công việc đang được tiến hành để tích hợp phiên bản xác định. Trong khi chờ đợi, các nhà phát triển hợp đồng Corda phải cẩn thận để không cho phép tính không xác định trong mã của họ.

Làm thế nào để chủ nghĩa trừng phạt của Ethereum so sánh với cách tiếp cận tiến hóa được thực hiện bởi MultiChain và Corda? Ưu điểm chính đối với Ethereum là giảm thiểu rủi ro - một máy ảo được xây dựng cho mục đích ít có khả năng chứa một nguồn vô tình không xác định. Mặc dù bất kỳ sự giám sát nào như vậy đều có thể được khắc phục bằng bản cập nhật phần mềm, nhưng nó sẽ gây gián đoạn cho bất kỳ chuỗi nào không đủ may mắn gặp phải nó. Tuy nhiên, vấn đề của Ethereum là Solidity và EVM tạo thành một hệ sinh thái nhỏ và non trẻ trong bối cảnh rộng hơn của các ngôn ngữ lập trình và môi trường thời gian chạy. Để so sánh, JavaScript và Java là hai ngôn ngữ hàng đầu trên Github, chạy trên hàng tỷ thiết bị kỹ thuật số và có thời gian chạy đã được tối ưu hóa qua nhiều thập kỷ. Có lẽ đây là lý do tại sao chuỗi khối Ethereum công khai đang xem xét chuyển đổi sang eWASM, một ngã ba xác định của tiêu chuẩn WebAssembly mới nổi.

Thuyết xác định bằng sự chứng thực

Khi nói đến thuyết xác định, Hyperledger Fabric áp dụng một cách tiếp cận hoàn toàn khác. Trong Fabric, khi một nút “client” muốn gửi một thông điệp đến một số mã chaincode, trước tiên nó sẽ gửi thông điệp đó đến một số nút “endorser”. Mỗi nút trong số các nút này thực thi mã chaincode một cách độc lập, tạo thành ý kiến ​​về thông báo của hiệu lực trên cơ sở dữ liệu của chaincode đó. Những ý kiến ​​này được gửi lại cho khách hàng cùng với chữ ký điện tử tạo thành một “chứng thực” chính thức. Nếu khách hàng nhận được đủ xác nhận về kết quả dự định, nó sẽ tạo ra một giao dịch có chứa các xác nhận đó và phát sóng nó để đưa vào chuỗi.

Để đảm bảo tính xác định, mỗi đoạn mã có một “chính sách xác nhận” xác định chính xác mức độ phê duyệt cần thiết để làm cho các giao dịch của nó hợp lệ. Ví dụ: chính sách của một chaincode có thể nêu rõ rằng yêu cầu xác nhận từ ít nhất một nửa số nút của blockchain. Người khác có thể yêu cầu sự chứng thực từ bất kỳ một trong ba bên đáng tin cậy nào. Dù bằng cách nào, mọi nút đều có thể kiểm tra độc lập xem đã nhận được các xác nhận cần thiết hay chưa.

Để làm rõ sự khác biệt, thuyết xác định trong hầu hết các nền tảng blockchain dựa trên câu hỏi: "Kết quả của việc chạy mã này trên dữ liệu này là gì?" - và chúng ta cần hoàn toàn chắc chắn rằng mọi nút sẽ trả lời câu hỏi này giống hệt nhau. Ngược lại, thuyết xác định trong Fabric dựa trên một câu hỏi khác: "Có đủ người tán thành đồng ý về kết quả của việc chạy mã này trên dữ liệu này không?" Trả lời đó là một vấn đề đếm khá đơn giản, và không có chỗ cho thuyết phi quyết định len lỏi vào.

Việc chứng thực theo thuyết xác định của Fabric có một số hệ quả thú vị. Đầu tiên, chaincode có thể được viết bằng nhiều ngôn ngữ lập trình khác nhau, vì chúng không cần phải được điều chỉnh cho phù hợp với thuyết xác định (Go, Java và JavaScript hiện được hỗ trợ). Thứ hai, chaincode có thể bị ẩn khỏi một số người tham gia blockchain, vì nó chỉ cần được thực thi bởi khách hàng và người xác nhận (bản thân cơ sở dữ liệu hiển thị trên toàn cầu). Cuối cùng và đáng chú ý nhất, Fabric chaincode có thể thực hiện những điều bị cấm trong các môi trường blockchain khác, chẳng hạn như kiểm tra thời tiết bằng cách sử dụng API web trực tuyến. Trong trường hợp xấu nhất, khi mọi người xác nhận nhận được một câu trả lời khác nhau từ API này, khách hàng sẽ không nhận được đủ xác nhận cho bất kỳ kết quả cụ thể nào và sẽ không có giao dịch nào diễn ra. (Cần lưu ý rằng các thành viên trong nhóm Vải vẫn giới thiệu sử dụng logic xác định bên trong chaincode, để tránh bất ngờ.)

Giá vải phải trả cho sự linh hoạt này là bao nhiêu? Nếu mục đích của blockchain là loại bỏ các bên trung gian khỏi một ứng dụng dựa trên cơ sở dữ liệu được chia sẻ, thì sự phụ thuộc của Fabric vào người chứng thực sẽ đi một bước dài khỏi mục tiêu đó. Đối với những người tham gia trong chuỗi, việc tuân theo các quy tắc của chaincode không còn đủ nữa - họ cũng cần một số nút khác đồng ý rằng họ đã làm như vậy. Thậm chí tệ hơn, một tập hợp con độc hại của những người chứng thực có thể phê duyệt các thay đổi cơ sở dữ liệu không tuân theo chaincode nào cả. Điều này mang lại cho người xác nhận nhiều quyền lực hơn so với người xác nhận trong các blockchain thông thường, những người có thể kiểm duyệt các giao dịch nhưng không thể vi phạm các quy tắc của blockchain. Các nhà phát triển ứng dụng chuỗi khối phải quyết định xem liệu sự đánh đổi này có hợp lý trong trường hợp cụ thể của họ hay không.

Thuyết định mạng	vải	Đa chuỗi	Ethereum	Corda
Mô hình	Xác nhận	Thời gian chạy đã điều chỉnh	Máy ảo được xây dựng có mục đích	Thời gian chạy đã điều chỉnh
Ngôn ngữ	Đi + Java + JavaScript	JavaScript	Độ cứng	Java + Kotlin
Khả năng hiển thị mã	Đối tác + người tán thành	Chuỗi khối	Chuỗi khối	Đối tác + người phụ thuộc
Thi hành	Không	Có	Có	Không phải bây giờ)

Phòng ngừa xung đột

Cho đến nay, chúng ta đã thảo luận về cách các nền tảng blockchain khác nhau thể hiện các quy tắc giao dịch trong mã và cách chúng đảm bảo một cách rõ ràng rằng mọi nút đều áp dụng các quy tắc đó giống nhau. Bây giờ là lúc để nói về khía cạnh thứ ba của cuộc thử thách của chúng ta: Làm thế nào để mỗi nền tảng đối phó với khả năng hai giao dịch có giá trị về bản thân chúng, xung đột với nhau? Trong ví dụ đơn giản nhất, hãy tưởng tượng rằng Alice có 10 đô la trong sổ cái tài chính và phát hai giao dịch - một giao dịch gửi 8 đô la cho Bob và giao dịch kia gửi 7 đô la cho Charlie. Rõ ràng, chỉ một trong những giao dịch này có thể được phép thành công.

Hai mô hình

Chúng ta có thể bắt đầu bằng cách nhóm cách tiếp cận của MultiChain và Corda về vấn đề này với nhau. Như đã mô tả trước đó, cả hai mô hình này đều sử dụng mô hình đầu vào - đầu ra để đại diện cho các giao dịch và các quy tắc của chúng, trong đó mỗi đầu vào giao dịch sử dụng một đầu ra giao dịch trước đó. Điều này dẫn đến một nguyên tắc đơn giản để ngăn ngừa xung đột: Mỗi đầu ra chỉ có thể được chi tiêu một lần. Bộ lọc MultiChain và hợp đồng Corda có thể dựa trên nền tảng tương ứng của chúng để thực thi hạn chế này một cách tuyệt đối. Vì 10 đô la của Alice được thể hiện bằng kết quả giao dịch trước đó, quy tắc chi tiêu một lần này sẽ tự động dừng việc cô gửi nó cho cả Bob và Charlie.

Bất chấp sự giống nhau này, điều quan trọng là phải chỉ ra sự khác biệt chính trong cách MultiChain và Corda ngăn chặn xung đột. Trong MultiChain, mọi nút đều thấy mọi giao dịch và do đó có thể xác minh độc lập rằng mỗi đầu ra chỉ được sử dụng một lần. Bất kỳ giao dịch nào thực hiện chi tiêu gấp đôi so với giao dịch đã xác nhận trước đó sẽ bị từ chối ngay lập tức và tự động. Ngược lại, ở Corda không có chuỗi khối toàn cầu, vì vậy cần có “công chứng viên” để ngăn chặn những khoản chi tiêu gấp đôi này. Mọi trạng thái đầu ra của Corda được giao cho một công chứng viên, người này phải ký bất kỳ giao dịch chi tiêu đầu ra đó, xác nhận rằng nó chưa được chi tiêu trước đó. Những người tham gia blockchain phải tin tưởng các công chứng viên tuân theo quy tắc này một cách trung thực và các công chứng viên độc hại có thể gây ra sự tàn phá theo ý muốn. Như với xác nhận trong Vải, điều này "chi tiêu một lần như một dịch vụ”Thiết kế có lợi thế về tính bảo mật nhưng giới thiệu lại các trung gian, đi ngược lại với chuỗi khối. (Điều quan trọng cần làm rõ là các công chứng của Corda có thể được điều hành bởi các nhóm người tham gia bằng cách sử dụng thuật toán đồng thuận, vì vậy tính toàn vẹn của sổ cái vẫn có thể được bảo vệ trước các tác nhân xấu riêng lẻ).

Hãy chuyển sang Ethereum. Để nhớ lại, Ethereum sử dụng các hợp đồng và thông điệp thay vì đầu vào và đầu ra. Do đó, các xung đột giao dịch như hai khoản thanh toán của Alice không hiển thị ngay lập tức với công cụ blockchain. Thay vào đó, chúng bị phát hiện và chặn bởi hợp đồng xử lý các giao dịch, sau khi đơn đặt hàng của họ được xác nhận trên chuỗi. Khi xử lý từng khoản thanh toán của Alice, hợp đồng xác minh xem số dư của cô ấy có đủ hay không. Nếu giao dịch trả 8 đô la cho Bob đến trước, giao dịch đó sẽ được xử lý như bình thường, để lại cho Alice 2 đô la trong tài khoản của cô ấy. Kết quả là, khi hợp đồng xử lý giao dịch thứ hai trả 7 đô la cho Charlie, nó thấy rằng Alice thiếu các khoản tiền cần thiết và giao dịch bị hủy bỏ.

Đầu ra so với hợp đồng

Cho đến nay, chúng tôi đã thấy hai kỹ thuật khác nhau để ngăn chặn các giao dịch xung đột - kết quả chi tiêu một lần trong MultiChain và Corda và xác minh dựa trên hợp đồng trong Ethereum. Vậy cái nào tốt hơn?

Để giúp trả lời câu hỏi này, chúng ta hãy xem xét ví dụ về tài khoản “1 trong 2 chữ ký đa dạng” giữ 100 đô la thay cho Gavin và Helen và cho phép một trong hai người chi tiêu số tiền đó một cách độc lập. Gavin hướng dẫn ứng dụng của mình trả 80 đô la cho Donna, và vài giây sau, Helen muốn gửi 40 đô la cho Edward. Vì không có đủ tiền cho cả hai khoản thanh toán, các giao dịch này chắc chắn sẽ xung đột. Trong trường hợp cả hai giao dịch đều được phát sóng, kết quả sẽ được xác định bởi điều kiện nào thực hiện đầu tiên trong chuỗi. Lưu ý rằng không giống như ví dụ của Alice, xung đột này là tình cờ, vì không ai cố gắng phá vỡ các quy tắc của ứng dụng - đơn giản là họ đã chọn thời điểm không may mắn.

Khi xem xét khả năng xảy ra xung đột này, câu hỏi quan trọng là: Sau khi Gavin gửi giao dịch của mình, sẽ mất bao lâu để nút của Helen biết rằng khoản thanh toán của cô ấy có thể thất bại? Khoảng thời gian này càng ngắn, Helen càng có nhiều khả năng bị ngăn chặn thực hiện khoản thanh toán đó, giúp cô và đơn đăng ký của cô khỏi bất ngờ sau đó.

Với mô hình đầu vào - đầu ra, bất kỳ xung đột nào giữa các giao dịch đều hiển thị trực tiếp với nền tảng blockchain, vì hai giao dịch sẽ cố gắng sử dụng cùng một đầu ra trước đó một cách rõ ràng. Trong MultiChain, điều này xảy ra ngay sau khi giao dịch của Gavin được truyền đến nút của Helen, thường là trong một giây hoặc ít hơn. Ở Corda, công chứng viên của đầu ra sẽ từ chối yêu cầu ký giao dịch của Helen, vì họ đã ký vào giao dịch của Gavin, vì vậy Helen sẽ ngay lập tức biết rằng thanh toán của cô ấy sẽ thất bại. (Mặc dù nếu công chứng viên Corda tự phân phối, cô ấy có thể phải đợi vài giây để được trả lời.) Dù bằng cách nào, không cần phải đợi giao dịch được xác nhận và đặt hàng trong blockchain.

Còn mô hình của Ethereum thì sao? Trong trường hợp này, không có cách nào ngay lập tức để nền tảng blockchain biết rằng xung đột sẽ xảy ra. Mặc dù nút của Helen có thể thấy giao dịch của Gavin trên mạng, nhưng nó không thể biết điều này sẽ ảnh hưởng như thế nào đến giao dịch của chính Helen, vì từ góc độ của nó, đây chỉ đơn giản là hai thông điệp được gửi đến cùng một hợp đồng. Có lẽ mười giây sau, khi thứ tự cuối cùng của các giao dịch xung đột được xác nhận trên blockchain, nút của Helen sẽ tính toán lại kết quả thực tế thay vì kết quả mong đợi và ứng dụng của cô ấy sẽ cập nhật hiển thị của nó cho phù hợp. Trong khi đó, cả Gavin và Helen sẽ bị bỏ lại trong bóng tối.

Nhưng chúng ta không nên kết luận từ điều này rằng mô hình đầu vào - đầu ra luôn hoạt động tốt nhất. Hãy xem xét một biến thể trong kịch bản ví dụ của chúng tôi, trong đó cả Gavin và Helen đều yêu cầu thanh toán 40 đô la nhỏ hơn từ số dư ban đầu là 100 đô la, chính xác vào cùng một thời điểm. Trong mô hình đầu vào - đầu ra, các giao dịch này sẽ xung đột, vì cả hai đều chi tiêu cùng một hàng cơ sở dữ liệu có chứa 100 đô la đó và chỉ một trong các khoản thanh toán sẽ thành công. Nhưng trong Ethereum, cả hai giao dịch sẽ được xử lý thành công, bất kể đơn hàng cuối cùng của chúng là gì, vì tài khoản có đủ tiền cho cả hai. Trong trường hợp này, Ethereum đáp ứng trung thực hơn ý định của Gavin và Helen.

Bộ đọc-ghi

Cuối cùng, hãy nói về Fabric, phương pháp tiếp cận dựa trên sự chứng thực là sự kết hợp của hai kỹ thuật này. Như đã giải thích trước đó, khi một nút "client" của Fabric muốn gửi một thông điệp đến một hợp đồng, trước tiên nó sẽ yêu cầu một số nút xác nhận thực hiện thông điệp đó thay cho nó. Các nút xác nhận làm như vậy theo cách tương tự như Ethereum - chạy hợp đồng dựa trên cơ sở dữ liệu cục bộ của chúng - nhưng quá trình này được quan sát thay vì áp dụng ngay lập tức. Mỗi trình xác nhận ghi lại tập hợp các hàng sẽ được đọc và ghi, đồng thời lưu ý phiên bản chính xác của các hàng đó tại thời điểm đó. “Tập hợp đọc-ghi” của các hàng được phiên bản này được tham chiếu rõ ràng trong xác nhận và được bao gồm trong giao dịch mà khách hàng phát đi.

Xung đột giữa các giao dịch của Fabric được giải quyết sau khi đơn hàng của họ được hoàn tất trong chuỗi. Mọi nút xử lý từng giao dịch một cách độc lập, kiểm tra các chính sách xác nhận và áp dụng các thay đổi cơ sở dữ liệu được chỉ định. Tuy nhiên, nếu một giao dịch đọc hoặc ghi một phiên bản hàng cơ sở dữ liệu đã được sửa đổi bởi một giao dịch trước đó, thì giao dịch thứ hai đó sẽ bị bỏ qua. Để quay lại các khoản thanh toán xung đột của Alice cho Bob và Charlie, cả hai giao dịch này sẽ đọc và sửa đổi cùng một phiên bản hàng, có chứa $ 10 mà Alice đã bắt đầu. Vì vậy, giao dịch thứ hai sẽ được hủy bỏ một cách an toàn và tự động.

Phương pháp giải quyết xung đột của Fabric hoạt động tốt, nhưng về mặt hiệu suất và tính linh hoạt, nó kết hợp những điểm kém nhất trong hai mô hình trước đó. Bởi vì xác nhận chuyển đổi các giao dịch thành các bộ đọc-ghi cụ thể, các khoản thanh toán 40 đô la đồng thời nhưng tương thích của Gavin và Helen sẽ dẫn đến xung đột mà Ethereum tránh. Tuy nhiên, Fabric không đạt được lợi thế về tốc độ của mô hình đầu vào - đầu ra, vì những người xác nhận thực thi hợp đồng dựa trên phiên bản mới nhất của cơ sở dữ liệu được blockchain xác nhận, bỏ qua các giao dịch chưa được xác nhận. Vì vậy, nếu Helen bắt đầu thanh toán của cô ấy vài giây sau Gavin, nhưng trước khi Gavin được xác nhận trên blockchain, Fabric sẽ tạo ra các giao dịch xung đột mà một mô hình đầu vào - đầu ra thuần túy tránh được.

Phòng ngừa xung đột	vải	Đa chuỗi	Ethereum	Corda
Mô hình	Bộ đọc-ghi	Chi tiêu một lần	Kiểm tra hợp đồng	Chi tiêu một lần
Xác minh	Độc lập	Độc lập	Độc lập	Công chứng viên đáng tin cậy
Tốc độ	~ 10 giây (xác nhận)	~ 1s (lan truyền)	~ 10 giây (xác nhận)	0 ~ 5s (công chứng)

Một sự lựa chọn phức tạp

Trong phần này, chúng tôi đã xem xét nhiều cách khác nhau trong đó Corda, Ethereum, Fabric và MultiChain giải quyết những thách thức chính của “hợp đồng thông minh” hoặc mã ứng dụng được nhúng trong blockchain. Và mỗi nền tảng có các câu trả lời khác nhau cho ba câu hỏi cốt lõi của chúng tôi: Các quy tắc giao dịch được thể hiện như thế nào? Làm thế nào mã được thực thi một cách xác định? Và làm thế nào để chúng ta ngăn chặn xung đột?

Vậy ai là người chiến thắng trong cuộc thi hợp đồng thông minh của chúng tôi? Rõ ràng là bây giờ không có câu trả lời đơn giản. Mỗi nền tảng đại diện cho sự đánh đổi đa chiều phức tạp giữa tính linh hoạt, đơn giản, hiệu suất, không trung gian, an toàn và bảo mật. Vì vậy, việc lựa chọn nền tảng cho một ứng dụng cụ thể phải bắt đầu bằng sự hiểu biết chi tiết về mô hình tin cậy của ứng dụng đó, các loại giao dịch mà nó liên quan và các dạng xung đột có thể xảy ra của chúng. Nếu bạn thấy ai đó đang thúc đẩy một giải pháp hợp đồng thông minh cụ thể trước khi họ biết câu trả lời cho những câu hỏi này, tôi khuyên bạn nên lịch sự nhưng kiên quyết nhấn mạnh rằng họ áp dụng một cách tiếp cận "thông minh hơn".

Xin vui lòng gửi bất kỳ ý kiến trên LinkedIn.