Trang chủ Tạp chí Khám phá Bitcoin : Hợp đồng kỹ thuật số

Khám phá Bitcoin [Phần 6]: Hợp đồng kỹ thuật số

26/09/2019 05:30

Đây là phần thứ sáu của bitcoiner Giacomo Zucco’s series “Khám phá Bitcoin: Tổng quan ngắn gọn từ Caveman đến Lightning Network”. Tìm hiểu thêm về phần giới thiệu và khám phá Bitcoin phần 1: Thời gian, phần 2: Con người, phần 3: Tiền tệ, phần 4: Bước ngoặc sai lầm (cần một kế hoạch mới) và phần 5: Sự khan hiếm kỹ thuật số.

Trong bài viết lần này, chúng tôi sẽ dựa trên ý tưởng sử dụng các câu đố kỹ thuật số như một cách để tái tạo sự khan hiếm và về tầm quan trọng của cơ chế kiểm soát cung ứng để cung cấp độ bền cho tiền kỹ thuật số, từ đó khám phá ra các khái niệm về chứng minh quyền sở hữu thông qua chữ ký cũng như chữ viết, và kỹ thuật này được gọi là CoinJoin.

Chứng minh quyền sở hữu: Chữ ký

Kế hoạch B lần thứ hai mang lại cho chúng tôi là tập trung vào chủ đề của con người và tả lời cho câu hỏi “Là ai?”.

Bạn đã thiết lập các quy định để phát hành sats mới, nhưng việc chuyển khoản của họ thì sao? Ai được phép thay đổi dữ liệu trong bảng cân đối kế toán chung và chuyển quyền sở hữu?

Nếu có một cơ quan trung ương chịu trách nhiệm phân lại các sats, theo hướng dẫn của chủ sở hữu hiện tại (có thể đăng nhập vào hệ thống bằng cách tiếp cận tên người dùng và mật khẩu thông thường, tương tự như trong thử nghiệm vàng điện tử trước đây của bạn), sẽ có Mallory làm bạn dễ bị thất bại một lần nữa: Tại sao sau đó còn bận tâm đến việc chuyển từ vàng vật chất sang khan hiếm kỹ thuật số dựa trên PoW? Mặt khác, nếu mỗi người dùng có quyền bình đẳng để xác định lại quyền sở hữu thì hệ thống của bạn hoàn toàn không thể hoạt động: Mọi người sẽ được khuyến khích liên tục chuyển nhượng sats của những người khác cho chính bản thân họ. Bạn cần một số loại giao thức xác định thẩm quyền nhất quán mà mọi người có thể kiểm tra độc lập.

Giải pháp là một kỹ thuật mã hóa được gọi là “chữ ký kỹ thuật số”. Nó hoạt động như thế này: Đầu tiên, Alice chọn một số ngẫu nhiên gọi là “khóa riêng của mật mã”, nơi mà cô sẽ giữ bí mật tuyệt đối. Sau đó, cô chuyển con số này thông qua một hàm toán học đặc biệt, dễ áp dụng theo một hướng nhưng thực tế không thể đảo ngược. Kết quả là một con số khác gọi là “khóa công khai”, mà Alice không giữ bí mật gì cả: Thay vào đó, cô đảm bảo rằng Bob sẽ biết về nó. Cuối cùng, cô chuyển khóa riêng và tin nhắn qua hàm thứ hai cũng khó đảo ngược dẫn đến một con số rất lớn gọi là “chữ ký của người dùng”. Một chức năng toán học thứ ba và cuối cùng có thể được Bob áp dụng cho tin nhắn, chữ ký và khóa công khai của Alice, dẫn đến xác minh tích cực hoặc tiêu cực. Nếu kết quả là khả quan, anh ta có thể chắc chắn rằng Alice đã ủy quyền cho tin nhắn đó “xác thực” (authentication), có nghĩa là sau đó cô sẽ không thể từ chối ủy quyền đó “tin nhắn không từ chối” (non-repudiation) và tin nhắn đó không bị thay đổi trong lúc đi qua “toàn vẹn” (integrity).

Nói cách khác, nó tương tự như chữ ký viết tay dễ dàng cho mọi người kiểm tra đối với một số mẫu công khai, nhưng khó sao chép nếu không phải là chủ sở hữu của bàn tay chính xác (correct hand). Hoặc đóng dấu bằng sáp: dễ dàng để mọi người có thể kiểm tra đối với sổ đăng ký con dấu công khai, nhưng khó sao chép nếu không có khuôn sáp chính xác.

Vì vậy, bạn thay đổi giao thức của mình để tạo ra các phân số bằng chứng công việc có thể tái sử dụng độc lập thông qua chữ ký điện tử. Mô hình đầu tiên bạn triển khai được xem là tầm thường: Mỗi người dùng độc lập tạo một khóa riêng và tạo một “tài khoản” công khai, được gắn nhãn với khóa chung tương ứng. Khi người dùng muốn chuyển quyền sở hữu, họ tạo một tin nhắn bao gồm tài khoản của họ cùng với tài khoản người nhận và số lượng sats họ muốn chuyển. Sau đó, họ ký điện tử và phát đi trong khi mọi người đều có thể xác minh.

Điều khá thú vị là một kế hoạch tương tự có thể được sử dụng bởi nhiều nhà phát triển nổi tiếng (nhưng có thể là giả danh) để ký các phiên bản phần mềm khác nhau để họ có thể tự do thay đổi, cải thiện, sửa chữa, cập nhật, kiểm tra, xem xét nó và bất kỳ người dùng cuối nào của hệ thống của bạn cũng có thể xác minh độc lập các chữ ký trước khi vận hành phiên bản ưa thích của chúng, tận dụng một mạng lưới sựu tin cậy bị thu nhỏ và phân mảnh, mà không cần một cơ quan duy nhất phân phối phần mềm. Quá trình này cho phép phân cấp mã phù hợp.

Script và “hợp đồng thông minh”

Bạn không muốn giới hạn các quy định mà mọi đồng nghiệp đều phải kiểm tra trước khi chấp thuận bất kỳ thay đổi nào trong bảng cân đối kế toán, chỉ đơn thuần là tính hợp lệ của chữ ký số.

Bạn quyết định rằng mỗi tin nhắn cũng có thể bao gồm một “script”: một danh sách các hướng dẫn mô tả các điều kiện bổ sung mà tài khoản người nhận (hoặc tài khoản) sẽ phải đáp ứng để chi tiêu lại lần nữa. Ví dụ: người gửi có thể yêu cầu kết hợp một số khóa bí mật (kết hợp hoặc phân tách) hoặc thời gian chờ cụ thể trước khi chi tiêu. Bắt đầu từ những việc rất đơn giản (và dễ kiểm toán) này, có thể xây dựng các hợp đồng thông minh phức tạp có thể lập nên và hơn nữa kiếm tiền một cách hiệu quả “có thể lập trình” (programmable) ngay cả khi không có các bên trung tâm.

Các vấn đề về “bóng tối” (darknes) và sự mở rộng (scaleness)

Không giống như một hệ thống nhắn tin được mã hóa (trong đó nếu Alice gửi cho Bob một số tin nhắn, chỉ Bob mới có thể đọc chúng), kế hoạch của bạn không thực sự được tối ưu hóa cho “bóng tối” (nếu Alice gửi sats cho Bob, tin nhắn của cô sẽ phải được tiết lộ ra ngoài không nằm trong phạm vi của Bob – ít nhất là cho những người sẽ nhận được những sats tương tự sau này).

Tiền lưu thông. Người được trả tiền không thể tin tưởng vào bất kỳ giao dịch chuyển tiền nào (ngay cả khi được ký kết hợp lệ) nếu họ không thể xác minh rằng các khoản chuyển đã thực sự được chuyển cho người trả cụ thể đó hay chưa, và ngược lại, trở lại việc phát hành dựa trên PoW đầu tiên. Với đủ số lượng lưu hành của sats, các đồng nghiệp tích cực sẽ biết được một số lượng lớn các giao dịch trong quá khứ và các kỹ thuật phân tích pháp lý có thể được sử dụng để tương quan thống kê số lượng, thời gian, siêu dữ liệu và tài khoản, từ đó loại bỏ nhiều sự từ chối của họ.

Vấn đề đặt ra ở đây: hư đã thảo luận trong Phần 2, “bóng tối” là một đặc tính cơ bản của tiền, cả vì lý do kinh tế lẫn xã hội học.

Hợp đồng thông minh có thể làm cho vấn đề này trở nên tồi tệ hơn vì các điều kiện chi tiêu cụ thể được sử dụng để xác định việc triển khai phần mềm cụ thể hoặc chính sách tổ chức riêng biệt.

Sự thiếu “bóng tối” này nghiêm trọng hơn so với thử nghiệm ảnh hưởng đến e-gold trước đây của bạn: Đúng là trước đó, bạn đã lưu trữ hầu hết dữ liệu giao dịch trên các máy chủ trung tâm của mình, nhưng ít nhất là chỉ có bạn, trái ngược hoàn toàn với bất kỳ ai đã truy cập (bao gồm nhiều đại lý của Mallory). Hơn nữa, bạn có thể thực hiện một số chiến lược mã hoá đặc biệt tiên tiến để biến mình thành ít nhất một phần “mù” (blind) về những gì đang thực sự xảy ra giữa những người dùng của bạn.

Ngoài ra còn có một vấn đề nhỏ về quy mô liên quan đến thiết kế này: Chữ ký số khá lớn và chuỗi chuyển khoản mà người nhận thanh toán cần nhận để xác thực mọi thứ sẽ bao gồm nhiều chữ ký, khiến việc xác thực có thể trở nên tốn kém hơn. Hơn nữa, thay đổi tài khoản là khá khó để xác nhận song song.

Một mô hình mới: “CoinJoin”

Để giảm thiểu những vấn đề tương tự vậy, bạn quyết định thay đổi các thực thể cơ bản của mô hình từ các “tài khoản” ngân hàng thành một “tài khoản giao dịch không rõ ràng” (Unspent Transaction Outputs) (UTXOs).

Thay vì hướng dẫn chuyển sats từ tài khoản này sang tài khoản khác, mỗi tin nhắn hiện bao gồm một danh sách các UTXO cũ, đến từ các giao dịch trong quá khứ và đã “sử dụng” các thành phần. Và một danh sách các UTXO mới đã “tạo ra” các sản phẩm và sẵn sàng cho các giao dịch trong tương lai . Thay vì xuất bản một khóa công khai hay riêng lẽ được sử dụng làm tài liệu tham khảo chung (như ngân hàng IBAN hoặc địa chỉ email), Bob phải cung cấp khóa công khai mới, sử dụng một lần cho mỗi khoản thanh toán mà anh ta muốn nhận. Khi Alice trả tiền cho anh ta, cô ta ký một tin nhắn thông báo rằng “mở khóa” sats từ một số UTXO được tạo trước đó và khóa lại một lần nữa vào một số UTXO mới.

Cũng giống với tiền mặt thực tế, các hóa đơn có thể chi tiêu không phải lúc nào cũng phù hợp với yêu cầu thanh toán – thường đòi hỏi phải thay đổi. Ví dụ, nếu Alice muốn trả 1.000 sats cho Bob, nhưng cô ấy chỉ kiểm soát một số UTXO khóa 700 sats cho mỗi cái, cô ấy sẽ ký một giao dịch tiêu thụ hai trong số 700 sats UTXO đó (mở khóa tổng số 1.400 sats) và tạo ra hai UTXOs mới: một liên kết với các khóa của Bob là khóa thanh toán (1.000 sats) và một khóa khác được liên kết với các khóa của Alice là khóa thay đổi (400 sats).

Với điều kiện mọi người không sử dụng các khóa tái sử dụng cho các khoản thanh toán khác nhau, thiết kế này làm tăng “bóng tối” trong chính nó. Nhưng thậm chí còn hơn thế khi người dùng của bạn bắt đầu nhận ra rằng các UTXO được tiêu thụ và tạo ra bởi một giao dịch duy nhất không phải đến từ hai thực thể. Alice có thể tạo một tin nhắn chi tiêu các UTXO cũ mà cô ấy kiểm soát và tạo các UTXO mới (được liên kết với Bob), sau đó cô ấy có thể chuyển tin nhắn đó cho Carol, người chỉ cần thêm các UTXO cũ mà cô ấy muốn sử dụng và các UTXO mới (liên kết với Daniel) muốn tạo. Cuối cùng, Alice và Carol đều ký và phát thông điệp tổng hợp (trả cả Bob và Daniel).

Việc sử dụng đặc biệt này của mô hình UTXO có tên là “CoinJoin”. (Cảnh báo kích hoạt: Trong lịch sử Bitcoin thực tế, việc sử dụng này không phải là lý do thiết kế của Satoshi cho chính mô hình UTXO nhưng được các nhà phát triển khác phát hiện ra như một bước ngoặt tiềm năng nhiều năm sau khi ra mắt). Nó phá vỡ khả năng liên kết thống kê giữa các đầu ra, trong khi vẫn bảo tồn cái được gọi là “hoá trị” (atomicity): Các giao dịch hoàn toàn hợp lệ hoặc không hợp lệ, do đó Alice và Carol không thể tin tưởng lẫn nhau. (Nếu một trong số họ cố gắng thay đổi thư đẫ được ký một phần trước khi thêm chữ ký của riêng họ, chữ ký hiện tại sẽ không hợp lệ).

Có một sự thay đổi xảy ra đối với hệ thống của bạn có thể thực sự cải thiện tình hình hơn nữa: một sơ đồ chữ ký kỹ thuật số khác thay thế cho hệ thống chữ ký kỹ thuật số hiện đang sử dụng, đó là “tuyến tính trong các chữ ký”. Điều đó có nghĩa là: khi nhận hai khoá riêng (không có gì ngoài hai con số), ký cùng một thông điệp với nhau và cộng các kết quả chữ ký lại với nhau (cũng không có gì ngoài hai con số rất lớn), kết quả xảy ra là chữ ký chính xác tương ứng với tổng của hai các khóa công khai liên quan đến hai khóa riêng ban đầu.

Điều này nghe có vẻ khó hiểu, nhưng hàm ý rất đơn giản: Alice và Carol, khi CoinJoining, có thể thêm chữ ký cá nhân của họ và chỉ phát ra số tiền mà mọi người có thể xác minh đối với tổng số khóa công khai của họ. Vì như chúng tôi đã nói, chữ ký là phần giao dịch “nặng” (heaviest) nhất của trực tuyến, khả năng phát sóng chỉ là một thay vì nhiều thứ sẽ tiết kiệm được nhiều tài nguyên. Các nhà quan sát bên ngoài cuối cùng sẽ nghi ngờ mọi giao dịch là CoinJoin, vì nhiều người dùng có thể sau khi đạt được hiệu quả. Giả định này sẽ phá vỡ hầu hết các giải pháp pháp lý.

Ngay cả khi không có cải tiến xa hơn, bằng cách nào đó mô hình UTXO đã tăng tỷ lệ: Không giống như thay đổi trạng thái trong mô hình tài khoản, nó cho phép sự phê chuẩn được xử lý theo đợt và song song một cách hiệu quả.

Cho đến nay, bạn đã học được:

bạn có thể phân cấp quyền sở hữu bằng chữ ký kỹ thuật số để chuyển nhượng
bạn có thể biến các giao dịch thành các “hợp đồng” có thể lập trình được với một hệ thống script
một mô hình phức tạp hơn được gọi là CoinJoin có thể làm tăng thêm “bóng tối” và “độ rộng”.

Nhưng giờ đây, người dùng của bạn có thể phát hành sats và chuyển chúng theo cách hoàn toàn phi tập trung, làm sao họ có thể chắc chắn rằng một trình tự thời gian được tuân theo, ngăn chặn các cuộc tấn công chi tiêu kép hoặc cố gắng sửa đổi lịch trình lạm phát? Chúng tôi sẽ trả lời này trong phần cuối cùng, Khám phá Bitcoin Phần 7: Những mảnh ghép còn thiếu.