Giới thiệu về Blockchain

Có lẽ bạn đã nghe blockchain được mô tả là "tiền kỹ thuật số" hoặc "tương lai của internet." Những giải thích này hoàn toàn bỏ lỡ điểm chính.

Blockchain là các hệ thống phân tán: mạng lưới các máy tính phải đồng ý về dữ liệu chung mà không cần tin tưởng lẫn nhau. Khóa học này dạy blockchain từ các nguyên lý cơ bản: các vấn đề hệ thống phân tán mà nó giải quyết, cách nó giải quyết chúng, và tại sao những đánh đổi lại quan trọng.

Hãy bắt đầu bằng việc hiểu tại sao xây dựng hệ thống phân tán là một trong những vấn đề khó nhất trong khoa học máy tính.

Hệ thống Phân tán

Hầu hết mọi người nghĩ rằng việc mở rộng từ một máy tính lên nhiều máy chỉ là "nhiều hơn cùng một thứ." Điều đó giống như nghĩ rằng điều phối một người cũng giống như điều phối một nghìn người trên các múi giờ khác nhau và có thể không phải lúc nào cũng liên lạc được.

Khi bạn viết code trên một máy tính duy nhất, bạn sống trong một thế giới có thể dự đoán:

• Các thao tác hoặc thành công hoặc thất bại ngay lập tức
• Dữ liệu không thay đổi một cách bí ẩn giữa các lần đọc
• Thời gian tiến về phía trước một cách nhất quán
• Khi bạn lưu thứ gì đó, nó thực sự được lưu

Hãy lấy một hệ thống ngân hàng đơn giản. Chuyển $100 từ Alice cho Bob trong trường hợp đó cực kỳ dễ dàng:

def transfer(from_account, to_account, amount):
    if from_account.balance >= amount:
        from_account.balance -= amount
        to_account.balance += amount
        return "Transfer successful"
    return "Insufficient funds"

Điều này hoạt động hoàn hảo... cho đến khi bạn cần mở rộng quy mô.

Ngân hàng của bạn phát triển vượt quá khả năng xử lý của một máy tính, vì vậy bây giờ bạn chia tài khoản đều trên các cơ sở dữ liệu khác nhau:

• Server A: Tài khoản từ 1 đến 1,000,000
• Server B: Tài khoản từ 1,000,001 đến 2,000,000
• Server C: Tài khoản từ 2,000,001 đến 3,000,000

Bây giờ Alice (trên Server A) muốn gửi $100 cho Bob (trên Server B). Việc chuyển tiền đơn giản đó trở thành:

def distributed_transfer(alice_server, bob_server, amount):
    # Check Alice's balance on Server A
    if alice_server.get_balance("alice") >= amount:
        alice_server.deduct("alice", amount)    # Step 1
        bob_server.add("bob", amount)           # Step 2
        return "Transfer successful"
    return "Insufficient funds"

Vẫn có vẻ đơn giản? Đây là những gì có thể xảy ra sai:

• Phân mảnh Mạng: Kết nối giữa các server thất bại ngay sau Bước 1 nhưng trước Bước 2. $100 của Alice biến mất vào khoảng không kỹ thuật số.
• Server Crash: Server B crash sau khi nhận lệnh "thêm tiền" nhưng trước khi xác nhận đã xử lý. Bob có nhận được tiền không? Không ai biết.
• Race Condition: Hai giao dịch chuyển tiền từ Alice xảy ra đồng thời. Cả hai đều kiểm tra số dư $100 của cô ấy, thấy rằng cô ấy có đủ tiền, và cả hai đều tiến hành. Alice bây giờ đã chi $100 mà cô ấy không có.

Định lý CAP

Năm 1999, nhà khoa học máy tính Eric Brewer đã công thức hóa Định lý CAP, nói rằng bất kỳ hệ thống phân tán nào chỉ có thể đảm bảo tối đa hai trong ba thuộc tính sau:

• Tính nhất quán (Consistency - C): Tất cả server luôn hiển thị cùng một dữ liệu. Khi số dư của Alice thay đổi trên Server A, mọi server khác ngay lập tức phản ánh điều này.
• Tính khả dụng (Availability - A): Hệ thống tiếp tục hoạt động ngay cả khi server crash. Nếu Server A ngừng hoạt động, người dùng vẫn có thể truy cập tài khoản thông qua Server B và C.
• Khả năng chịu phân mảnh (Partition Tolerance - P): Hệ thống tồn tại qua các lỗi mạng chia server thành các nhóm bị cô lập.

Chúng ta phải đảm bảo khả năng chịu phân mảnh vì phân vùng mạng là không thể tránh khỏi: cáp bị cắt, router hỏng, trung tâm dữ liệu mất điện. Điều này khiến chúng ta phải chọn giữa Tính nhất quán HOẶC Tính khả dụng.

Các hệ thống ngân hàng truyền thống thường chọn Tính nhất quán + Khả năng chịu phân mảnh (Hệ thống CP). Họ thà tắt hệ thống còn hơn hiển thị số dư tài khoản không chính xác.

Các nền tảng mạng xã hội thường chọn Tính khả dụng + Khả năng chịu phân mảnh (Hệ thống AP). Họ thà để bạn đăng bài (ngay cả khi bạn bè không thể thấy ngay lập tức) còn hơn ngăn bạn đăng bài hoàn toàn.

Bài toán Byzantine Generals

Ngoài Định lý CAP, hầu hết các hệ thống phân tán giả định rằng những người tham gia là trung thực: họ có thể thất bại hoặc ngắt kết nối, nhưng họ sẽ không chủ động lừa dối lẫn nhau. Giả định này bị phá vỡ khi những người tham gia có thể là độc hại.

Bài toán Byzantine Generals, được các nhà khoa học máy tính công thức hóa năm 1982, minh họa thách thức này:

Bạn là một tướng Byzantine đang lên kế hoạch tấn công một thành phố kiên cố. Bạn có một số tướng đồng minh được bố trí xung quanh thành phố, mỗi người chỉ huy quân đội riêng của họ. Để thành công, bạn phải điều phối một cuộc tấn công đồng thời. Nếu một số tấn công trong khi những người khác rút lui, lực lượng tấn công sẽ bị tàn sát.

Bạn chỉ giao tiếp thông qua sứ giả, và một số tướng có thể là kẻ phản bội muốn cuộc tấn công thất bại. Kẻ phản bội có thể:

• Gửi tin nhắn "tấn công" cho một số tướng và "rút lui" cho những người khác
• Sửa đổi tin nhắn từ các tướng trung thành khi chúng đi qua
• Phối hợp với các kẻ phản bội khác để tối đa hóa sự nhầm lẫn

Làm thế nào bạn đạt được sự đồng thuận về "tấn công" hoặc "rút lui" khi bạn không thể phân biệt tướng trung thành với kẻ phản bội, và bạn không thể tin tưởng các kênh giao tiếp?

Điều này có vẻ không thể. Trong nhiều thập kỷ, các nhà khoa học máy tính tin rằng bạn không thể xây dựng một hệ thống đồng thời:

• Chịu được lỗi Byzantine (hoạt động bất chấp các thành phần độc hại)
• Không cần phép (bất kỳ ai cũng có thể tham gia mà không cần phê duyệt)
• Phi tập trung (không có cơ quan trung ương)

Sau đó vào năm 2008, một người tự gọi mình là Satoshi Nakamoto đã chứng minh họ sai.

Bitcoin: blockchain đầu tiên

Bitcoin là triển khai thực tế đầu tiên của công nghệ blockchain. Mặc dù các thành phần riêng lẻ đã tồn tại trước đó (băm mật mã, chữ ký số, mạng ngang hàng), Satoshi là người đầu tiên kết hợp chúng để giải quyết vấn đề chi tiêu kép cho tiền tệ kỹ thuật số.

Blockchain, hay "chuỗi các khối" như được gọi trong whitepaper Bitcoin gốc, cuối cùng đã tạo ra một hệ thống vừa phân tán, vừa chịu được lỗi Byzantine, và vừa không cần phép đồng thời.

Đột phá không phải là cố gắng xác định ai đáng tin cậy; mà là làm cho việc nói dối tốn kém về mặt kinh tế hơn việc nói thật. Proof of Work thực hiện điều này bằng cách yêu cầu những người tham gia tiêu thụ năng lượng tính toán thực để đề xuất thay đổi. Kẻ tấn công sẽ cần tiêu thụ nhiều tiền điện hơn những gì họ có thể thu được từ một cuộc tấn công.