2.3. Đồng thuận không danh tính sử dụng chuỗi khối
Trong phần này, chúng ta nghiên cứu các chi tiết kỹ thuật của thuật toán đồng thuận của Bitcoin. Nhớ lại rằng các nút Bitcoin không có danh tính lâu dài và bền bỉ. Đây là một điểm khác biệt so với các thuật toán đồng thuận phân tán truyền thống. Một lý do giải thích cho việc thiếu danh tính liên tục này là trong hệ thống ngang hàng, không có cơ quan trung ương để chỉ định danh tính cho những người tham gia và xác minh rằng họ không tạo các nút mới theo ý muốn. Thuật ngữ kỹ thuật cho đây là một cuộc tấn công Sybil. Sybils chỉ là bản sao của các nút mà một kẻ thù độc hại có thể tạo ra để làm cho nó trông giống như có rất nhiều người tham gia khác nhau, trong khi trên thực tế, tất cả những người tham gia giả đó thực sự bị kiểm soát bởi cùng một kẻ thù. Lý do khác là tính bút danh vốn dĩ là một mục tiêu của Bitcoin. Ngay cả khi có thể hoặc dễ dàng thiết lập danh tính cho tất cả các nút hoặc tất cả những người tham gia, chúng ta sẽ không nhất thiết muốn làm điều đó. Mặc dù Bitcoin không đảm bảo tính ẩn danh mạnh mẽ ở chỗ các giao dịch khác nhau mà một người thực hiện thường có thể được liên kết với nhau, nhưng nó có đặc tính mà không ai bị buộc phải tiết lộ danh tính ngoài đời thực của họ (ví dụ: tên hoặc địa chỉ IP của họ) để tham gia. Và đó là một thuộc tính quan trọng và là đặc điểm trung tâm của thiết kế Bitcoin.
Nếu các nút có danh tính, thiết kế sẽ dễ dàng hơn. Đầu tiên, danh tính sẽ cho phép chúng ta đưa vào các hướng dẫn giao thức của biểu mẫu, “Bây giờ là nút có số thấp nhấtID nên thực hiện một số bước. ” Không có danh tính, tập hợp các hướng dẫn có thể bị hạn chế hơn. Nhưng lý do thứ hai, nghiêm trọng hơn nhiều, để các nút có danh tính là vì bảo mật. Nếu các nút đã được xác định và việc tạo danh tính nút mới không phải là chuyện nhỏ, thì chúng ta có thể đưa ra giả định về số lượng nút độc hại và chúng ta có thể lấy các thuộc tính bảo mật dựa trên những con số đó. Vì cả hai lý do này, việc thiếu danh tính gây ra những khó khăn cho giao thức đồng thuận trong Bitcoin.
Chúng ta có thể bù đắp cho việc thiếu danh tính bằng cách đưa ra một giả định yếu hơn. Giả sử bằng cách nào đó có khả năng chọn một nút ngẫu nhiên trong hệ thống. Một phép tương tự có động lực tốt cho điều này là xổ số hoặc xổ số để bán hàng, hoặc bất kỳ hệ thống thực tế nào mà ở đó khó theo dõi mọi người, cung cấp danh tính cho họ và xác minh những danh tính đó. Những gì chúng ta làm trong những bối cảnh đó là phát mã thông báo (tokens), vé hoặc thứ gì đó tương tự. Điều đó cho phép chúng ta sau này chọn một ID mã thông báo ngẫu nhiên và gọi cho chủ sở hữu của ID đó. Vì vậy, hiện tại, hãy tin tưởng và giả định rằng có thể chọn một nút ngẫu nhiên từ mạng Bitcoin theo cách này. Ngoài ra, giả sử hiện tại, thuật toán tạo và phân phối mã thông báo này đủ thông minh để nếu đối thủ cố gắng tạo nhiều nút Sybil, tất cả các Sybils đó cùng nhau sẽ chỉ nhận được một mã thông báo. Do đó, kẻ thù không thể nhân lên sức mạnh của mình bằng cách tạo ra các nút mới. Nếu bạn nghĩ rằng điều này là rất nhiều để giả định, đừng lo lắng. Trong Phần 2.4, chúng ta loại bỏ các giả định này và hiển thị chi tiết cách các thuộc tính tương đương với những điều này được thực hiện trong Bitcoin.
Đồng thuận ngầm
Giả định về việc lựa chọn nút ngẫu nhiên này có thể tạo ra một cái gì đó mà chúng ta gọi là sự đồng thuận ngầm. Có nhiều vòng trong giao thức của chúng ta, mỗi vòng tương ứng với một khối khác nhau trong chuỗi khối. Trong mỗi vòng, một nút ngẫu nhiên được chọn bằng cách nào đó và nút này sẽ đề xuất khối tiếp theo trong chuỗi. Không có thuật toán đồng thuận để chọn khối và không có bất kỳ hình thức bỏ phiếu nào. Nút được chọn đơn phương đề xuất khối tiếp theo trong chuỗi khối sẽ là gì. Nhưng nếu nút đó là độc hại thì sao? Chà, tồn tại một quy trình để xử lý điều đó, nhưng nó là một quy trình ngầm. Các nút khác sẽ ngầm chấp nhận hoặc từ chối khối đó bằng cách chọn có xây dựng trên đó hay không. Nếu chúng chấp nhận khối đó, chúng sẽ báo hiệu sự chấp nhận của chúng bằng cách mở rộng chuỗi khối và bao gồm cả khối được chấp nhận. Ngược lại, nếu chúng từ chối khối đó, chúng sẽ mở rộng chuỗi bằng cách bỏ qua khối đó và xây dựng trên khối trước đó mà chúng đã chấp nhận. Nhớ lại rằng mỗi khối chứa một hàm băm của khối mà nó mở rộng. Đây là cơ chế kỹ thuật cho phép các nút báo hiệu rằng chúng đang mở rộng khối nào.
Thuật toán đồng thuận Bitcoin (đơn giản hóa). Thuật toán này được đơn giản hóa ở chỗ nó giả định khả năng chọn một nút ngẫu nhiên theo cách không dễ bị tấn công bởi các cuộc tấn công của Sybil.
1. Các giao dịch mới được phát tới tất cả các nút.
2. Mỗi nút thu thập các giao dịch mới thành một khối.
3. Trong mỗi vòng, một nút ngẫu nhiên được phát khối của nó.
4. Các nút khác chỉ chấp nhận khối nếu tất cả các giao dịch trong đó là hợp lệ (chưa được sử dụng, chữ ký hợp lệ).
5. Các nút thể hiện sự chấp nhận của chúng đối với khối bằng cách thêm hàm băm của nó vào khối tiếp theo mà chúng tạo.
Bây giờ chúng ta hãy phân tích lý do tại sao thuật toán đồng thuận này hoạt động. Để làm điều này, hãy xem xét cách một kẻ thù ác ý—gọi cô ấy là Alice—có thể lật đổ quá trình này.
ĂN CẮP BITCOIN
Alice có thể chỉ đơn giản là ăn cắp bitcoin của người dùng khác tại một địa chỉ mà cô ấy không kiểm soát? Không. Ngay cả khi đến lượt Alice đề xuất khối tiếp theo trong chuỗi, cô ấy không thể ăn cắp bitcoin của người dùng khác. Làm như vậy sẽ yêu cầu Alice tạo một giao dịch hợp lệ sử dụng số tiền đó. Điều này sẽ yêu cầu Alice giả mạo chữ ký của chủ sở hữu, điều mà cô ấy không thể làm được nếu sử dụng sơ đồ chữ ký số an toàn. Vì vậy, miễn là mật mã cơ bản chắc chắn, cô ấy không thể chỉ đơn giản là đánh cắp bitcoin.
TẤN CÔNG TỪ CHỐI DỊCH VỤ
Hãy xem xét một cuộc tấn công khác. Giả sử rằng Alice thực sự không thích một số người dùng khác là Bob. Sau đó, Alice có thể quyết định rằng cô ấy sẽ không bao gồm bất kỳ giao dịch nào bắt nguồn từ địa chỉ của Bob trong bất kỳ khối nào mà cô ấy đề xuất đưa vào chuỗi khối. Nói cách khác, cô ấy đang từ chối sự phục vụ của Bob. Mặc dù đây là một đòn tấn công hợp lệ mà Alice có thể cố gắng sắp xếp, nhưng may mắn là nó không có gì khác hơn là một sự khó chịu nhỏ. Nếu giao dịch của Bob không lọt vào khối tiếp theo mà Alice đề xuất, anh ta sẽ chỉ đợi cho đến khi một nút trung thực có cơ hội đề xuất một khối, và sau đó giao dịch của anh ta sẽ đi vào khối đó. Vì vậy, đó cũng không thực sự là một cuộc tấn công tốt.
TẤN CÔNG CHI TIÊU GẤP ĐÔI
Alice có thể cố gắng khởi động một cuộc tấn công chi tiêu gấp đôi. Để hiểu cách hoạt động của nó, hãy giả sử rằng Alice là khách hàng của một người bán hoặc trang web trực tuyến nào đó do Bob điều hành, người cung cấp một số dịch vụ trực tuyến để đổi lấy thanh toán bằng bitcoin. Giả sử dịch vụ của Bob cho phép tải xuống một số phần mềm. Vì vậy, đây là cách một cuộc tấn công chi tiêu gấp đôi có thể hoạt động. Alice thêm một mặt hàng vào giỏ hàng của mình trên trang web của Bob và máy chủ yêu cầu thanh toán. Sau đó, Alice tạo một giao dịch Bitcoin từ địa chỉ của cô ấy đến địa chỉ của Bob và phát nó lên mạng. Giả sử rằng một số nút trung thực tạo ra khối tiếp theo và bao gồm giao dịch này trong khối đó. Vì vậy, bây giờ có một khối được tạo bởi một nút trung thực có chứa một giao dịch đại diện cho một khoản thanh toán từ Alice cho người bán Bob.
Hãy nhớ lại rằng một giao dịch là một cấu trúc dữ liệu có chứa chữ ký của Alice, một lệnh thanh toán cho khóa công khai của Bob và một hàm băm. Hàm băm này đại diện cho một con trỏ đến kết quả giao dịch trước đó mà Alice đã nhận và hiện đang chi tiêu. Con trỏ đó phải tham chiếu đến một giao dịch đã được bao gồm trong một số khối trước đó trong chuỗi đồng thuận.
Nhân tiện, lưu ý rằng có hai loại con trỏ băm khác nhau ở đây có thể dễ bị nhầm lẫn. Các khối bao gồm một con trỏ băm đến khối trước đó mà chúng đang mở rộng. Các giao dịch bao gồm một hoặc nhiều con trỏ băm đến kết quả đầu ra của giao dịch trước đó đang được sử dụng.
Hãy quay lại cách Alice có thể khởi động một cuộc tấn công chi tiêu gấp đôi. Khối mới nhất được tạo bởi một nút trung thực và bao gồm một giao dịch trong đó Alice trả tiền cho Bob để tải xuống phần mềm. Khi thấy giao dịch này được bao gồm trong chuỗi khối, Bob kết luận rằng Alice đã trả tiền cho anh ta và cho phép Alice tải xuống phần mềm. Giả sử nút ngẫu nhiên tiếp theo được chọn trong vòng tiếp theo tình cờ được điều khiển bởi Alice. Vì Alice có thể đề xuất khối tiếp theo, cô ấy có thể đề xuất một khối bỏ qua khối chứa khoản thanh toán cho Bob và thay vào đó chứa một con trỏ đến khối trước đó. Hơn nữa, trong khối mà cô ấy đề xuất, Alice bao gồm một giao dịch chuyển những đồng tiền mà cô ấy đang gửi cho Bob đến một địa chỉ khác mà chính cô ấy kiểm soát. Đây là một mô hình chi tiêu gấp đôi cổ điển. Vì hai giao dịch sử dụng cùng một đồng tiền, nên chỉ một trong số chúng có thể được đưa vào chuỗi khối. Nếu Alice thành công trong việc đưa khoản thanh toán đến địa chỉ của chính cô ấy trong chuỗi khối, thì giao dịch mà cô ấy trả cho Bob là vô ích, vì nó không bao giờ có thể được đưa vào sau này trong chuỗi khối (Hình 2.2).
HÌNH 2.2. Một nỗ lực chi tiêu gấp đôi. Alice tạo hai giao dịch: một trong đó cô ấy gửi bitcoin cho Bob và một giao dịch thứ hai, trong đó cô ấy chi tiêu gấp đôi số bitcoin đó bằng cách gửi chúng đến một địa chỉ khác mà cô ấy kiểm soát. Khi họ sử dụng cùng một số bitcoin, chỉ một trong số các giao dịch này có thể được đưa vào chuỗi khối. Các mũi tên giữa các khối là các con trỏ từ khối này đến khối trước mà nó mở rộng bằng cách bao gồm một hàm băm của khối trước đó trong nội dung của chính nó. CA được sử dụng để biểu thị một đồng xu do Alice sở hữu.
Làm cách nào để biết liệu nỗ lực chi tiêu gấp đôi này có thành công hay không? Chà, điều đó phụ thuộc vào khối nào cuối cùng sẽ kết thúc trong chuỗi đồng thuận dài hạn—khối có giao dịch Alice → Bob hoặc khối có giao dịch Alice → Alice. Điều gì quyết định khối nào sẽ được đưa vào? Các nút trung thực tuân theo chính sách mở rộng nhánh hợp lệ dài nhất, vậy chúng sẽ mở rộng nhánh nào? Không có câu trả lời đúng! Tại thời điểm này, hai nhánh có cùng độ dài—chúng chỉ khác nhau ở khối cuối cùng và cả hai khối này đều hợp lệ. Sau đó, nút chọn khối tiếp theo có thể quyết định xây dựng trên một trong hai khối đó và lựa chọn này sẽ quyết định phần lớn đến việc liệu cuộc tấn công chi tiêu kép có thành công hay không.
Một điểm tinh tế: từ quan điểm đạo đức, có sự khác biệt rõ ràng giữa khối chứa giao dịch trả tiền cho Bob và khối chứa giao dịch trong đó Alice gấp đôi chi những đồng tiền đó đến địa chỉ của chính cô ấy. Nhưng sự khác biệt này chỉ dựa trên kiến thức của chúng ta về câu chuyện Alice trả tiền cho Bob lần đầu tiên và sau đó cố gắng tăng gấp đôi chi tiêu. Tuy nhiên, từ quan điểm công nghệ, hai giao dịch này giống hệt nhau và cả hai khối đều có giá trị như nhau. Các nút đang xem xét điều này thực sự không có cách nào để phân biệt đâu là giao dịch hợp pháp về mặt đạo đức.
Trên thực tế, các nút thường tuân theo phương pháp mở rộng khối mà chúng phát hiện lần đầu trên mạng ngang hàng. Nhưng nó không phải là một quy tắc vững chắc. Và trong mọi trường hợp, do độ trễ của mạng, có thể dễ dàng xảy ra trường hợp khối mà một nút phát hiện đầu tiên thực sự là khối được tạo lần thứ hai. Vì vậy, có ít nhất một cơ hội nào đó mà nút tiếp theo được chọn để đề xuất một khối sẽ mở rộng khối chứa chi tiêu gấp đôi. Alice có thể cố gắng tăng khả năng điều này xảy ra hơn nữa bằng cách hối lộ nút tiếp theo để làm như vậy. Nếu nút tiếp theo xây dựng trên khối chi tiêu gấp đôi vì bất kỳ lý do gì, thì chuỗi này bây giờ sẽ dài hơn chuỗi bao gồm giao dịch với Bob. Tại thời điểm này, nút trung thực tiếp theo có nhiều khả năng tiếp tục xây dựng trên chuỗi này, vì nó dài hơn. Quá trình này sẽ tiếp tục, và ngày càng có nhiều khả năng khối chứa chi tiêu gấp đôi sẽ là một phần của chuỗi đồng thuận dài hạn. Ngược lại, khối chứa giao dịch gửi cho Bob hoàn toàn bị mạng bỏ qua—nó hiện được gọi là khối cũ hoặc khối mồ côi.
Bây giờ chúng ta hãy xem xét lại tình huống này theo quan điểm của Bob-the-merchant (Hình 2.3). Hiểu cách Bob có thể tự bảo vệ mình khỏi cuộc tấn công chi tiêu gấp đôi này là một phần quan trọng để hiểu về bảo mật Bitcoin. Khi Alice truyền phát giao dịch đại diện cho khoản thanh toán của cô ấy cho Bob, Bob đang lắng nghe trên mạng và nghe về giao dịch này ngay cả trước khi khối tiếp theo được tạo. Nếu Bob thậm chí còn ngu ngốc hơn chúng tôi đã mô tả trước đây, anh ta có thể hoàn tất quy trình thanh toán trên trang web và cho phép Alice tải xuống phần mềm ngay tại thời điểm đó. Đó được gọi là giao dịch không xác nhận (zero-confirmation transaction). Điều này dẫn đến một cuộc tấn công chi tiêu gấp đôi thậm chí cơ bản hơn so với cuộc tấn công được mô tả trước đây. Trước đây, để xảy ra cuộc tấn công chi tiêu gấp đôi, chúng ta phải giả định rằng một tác nhân độc hại kiểm soát nút đề xuất khối tiếp theo. Nhưng nếu Bob cho phép Alice tải xuống phần mềm trước khi giao dịch nhận được dù chỉ một xác nhận trên chuỗi khối, thì Alice có thể phát ngay một giao dịch chi tiêu gấp đôi và một nút trung thực có thể đưa nó vào khối tiếp theo thay vì giao dịch trả tiền Bob.
HÌNH 2.3. quan điểm của Bob the Merchant. Đây là nỗ lực chi tiêu gấp đôi của Alice theo quan điểm của Bob. Để tự bảo vệ mình khỏi cuộc tấn công này, Bob nên đợi để giải phóng hàng hóa cho đến khi giao dịch mà Alice trả cho anh ta được đưa vào chuỗi khối và có một số xác nhận.
Tuy nhiên, một thương gia thận trọng sẽ không phát hành phần mềm cho Alice ngay cả sau khi giao dịch được bao gồm trong một khối; anh ấy sẽ tiếp tục chờ đợi. Nếu Bob thấy Alice thực hiện thành công cuộc tấn công chi tiêu gấp đôi, anh ta nhận ra rằng khối chứa khoản thanh toán của Alice cho anh ta đã bị bỏ rơi. Anh ta nên từ bỏ giao dịch và không cho Alice tải xuống phần mềm. Thay vào đó, nếu điều đó xảy ra rằng mặc dù nỗ lực chi tiêu gấp đôi, nhưng một số nút tiếp theo vẫn xây dựng trên khối với giao dịch Alice → Bob, thì Bob sẽ tin tưởng rằng giao dịch này sẽ nằm trong chuỗi đồng thuận dài hạn.
Nói chung, giao dịch càng nhận được nhiều xác nhận thì khả năng giao dịch đó sẽ kết thúc trong chuỗi đồng thuận dài hạn càng cao. Nhớ lại rằng các nút trung thực luôn mở rộng nhánh hợp lệ dài nhất mà chúng tìm thấy. Cơ hội là nhánh ngắn hơn với chi gấp đôi sẽ bắt kịp với nhánh dài ngày càng trở nên nhỏ bé khi nhánh sau mọc dài hơn bất kỳ nhánh nào khác. Điều này đặc biệt đúng nếu chỉ một số ít các nút độc hại—để một nhánh ngắn hơn bắt kịp, một số nút độc hại sẽ phải được chọn liên tiếp.
Trên thực tế, xác suất chi tiêu gấp đôi giảm theo cấp số nhân với số lượng xác nhận. Vì vậy, nếu giao dịch mà bạn quan tâm đã nhận được k xác nhận, thì xác suất giao dịch chi tiêu gấp đôi sẽ kết thúc trên chuỗi đồng thuận dài hạn giảm xuống theo cấp số nhân dưới dạng hàm của k. Phương pháp heuristic phổ biến nhất được sử dụng trong hệ sinh thái Bitcoin là đợi sáu xác nhận. Không có gì thực sự đặc biệt về số sáu. Đó chỉ là sự cân bằng tốt giữa lượng thời gian bạn phải chờ và sự đảm bảo của bạn rằng giao dịch mà bạn quan tâm sẽ kết thúc trên chuỗi khối đồng thuận.
Tóm lại, bảo vệ chống lại các giao dịch không hợp lệ hoàn toàn là mật mã. Nhưng nó được thực thi bởi sự đồng thuận, có nghĩa là nếu một nút cố gắng bao gồm một giao dịch không hợp lệ về mặt mật mã, thì lý do duy nhất khiến giao dịch đó không kết thúc trong chuỗi đồng thuận lâu dài là vì phần lớn các nút đều trung thực và sẽ không bao gồm một giao dịch không hợp lệ trong chuỗi khối. Ngược lại, việc bảo vệ chống lại việc chi tiêu gấp đôi hoàn toàn là do sự đồng thuận. Mật mã không có gì để nói về điều này và hai giao dịch đại diện cho nỗ lực chi tiêu gấp đôi đều hợp lệ từ góc độ mật mã. Nhưng chính sự đồng thuận sẽ xác định cái nào sẽ kết thúc trong chuỗi đồng thuận lâu dài. Và cuối cùng, bạn không bao giờ chắc chắn 100% rằng giao dịch mà bạn quan tâm nằm trên nhánh đồng thuận. Nhưng đảm bảo xác suất theo cấp số nhân này khá tốt. Sau khoảng sáu giao dịch, hầu như không có khả năng bạn bị lừa.