Bitcoin – đồng tiền tự do (P.2)

Transaction-based system

phần trước, chúng ta đã biết rằng database system của Bitcoin không gì khác hơn là bao gồm rất nhiều các transaction. Chính vì vậy, system này đôi khi còn được gọi là transaction-based system. Mỗi transaction về cơ bản cho biết số tiền bao nhiêu được chuyển đi từ những tài khoản nào sang những tài khoản nào. Cho nên để trả lời câu hỏi: “số dư tài khoản này hiện tại là bao nhiêu?”, system phải truy vấn tất cả các transaction có dính líu tới tài khoản đó.

Thoạt nhìn qua, cách làm này có vẻ dở ẹc vì nó chậm. Tại sao không làm theo cách truyền thống? Tức là mỗi một tài khoản luôn đi kèm theo nó một số dư, mỗi khi muốn chuyển tiền từ tài khoản A sang tài khoản B, chỉ cần trừ bớt vào số dư của A và cộng thêm vào số dư của B. Cách truyền thống này không phù hợp trong một môi trường distributed như Bitcoin, bởi vì:

  • Hai thao tác “trừ bớt” và “cộng thêm” phải đảm bảo tính ACID. Và ACID trong distributed system không hề tầm thường.
  • Message dạng “trừ bớt và cộng thêm” không có tính idempotent. Trên network, message bị mất hoặc chậm trễ không phải là hiếm. Do đó một message có thể phải được gửi đi nhận lại nhiều lần, nếu phía nhận message mà thực thi cùng một message “trừ bớt và cộng thêm” nhiều lần, thì thật là thảm họa!

Tất nhiên, hai vấn đề trên là khá phổ biến trong distributed system và đều có giải pháp. Nhưng đó là những giải pháp đau khổ và ảnh hưởng nghiêm trọng tới performance của system.

Ngược lại, phương pháp transaction-based của Bitcoin có nhiều ưu điểm:

  • Một Bitcoin transaction rõ ràng là rất idempotent bởi nó luôn có một self-ID (chính là hash value của nội dung transaction). Nhờ vào self-ID này, cho dù chúng ta có nhận đi nhận lại cùng một transaction cũng không thành vấn đề. Bạn có thể thắc mắc là với cách truyền thống thì mỗi message cũng có self-ID vậy! OK, vậy là trong trường hợp nhiều message có cùng self-ID được lặp lại, bạn tưởng rằng chúng là một? Nhưng nhỡ chúng thực sự là những message khác nhau (bạn A thực sự muốn gửi cùng một số tiền nhiều lần cho bạn B) thì sao? Với Bitcoin transaction, chuyện này không thể xảy ra, vì nếu bạn A thực sự muốn chuyển lần nữa cho bạn B, thì transaction mới luôn có self-ID khác transaction cũ, hãy nhớ lại rằng một transaction luôn tham chiếu tới một hoặc nhiều transaction output khác (xem lại phần 1).
  • Một ưu điểm nữa là nó cho phép xem lại lịch sử của tài khoản một cách đầy đủ.
  • Performance vẫn nhanh nếu dùng database framework thích hợp. Bitcoin đang dùng LevelDB của Google. Với LevelDB thì vài chục GB dữ liệu hiện tại của Bitcoin không thấm tháp gì.

Coinbase transaction

Như đã nói trong phần 1, coinbase transaction (còn gọi là generation transaction) rất đặc biệt, nó không có input mà chỉ có output đút tiền vào túi “người đào”. Công việc tạo ra coinbase transaction gọi là “đào bitcoin”. Để tạo ra một hoặc nhiều coinbase transaction hợp lệ, “người đào” phải đi tìm một solution cho một task nào đấy.

Đứng từ phía tác giả Bitcoin, việc thiết kế các task và những ràng buộc cho solution là vô cùng quan trọng, nó phải đảm bảo hai yếu tố: task phải đủ khó, và việc ganh đua đi tìm solution phải công bằng. Cụ thể, chúng phải thỏa mãn những tính chất sau đây:

  1. Tại mỗi một thời điểm, số lượng task là hữu hạn nhưng sẽ được tăng lên khi thời gian trôi qua.
  2. Mỗi task phải có một self-ID để phân biệt.
  3. Mỗi task phải có một độ khó, có thể bằng nhau hoặc khác nhau.
  4. Độ khó của mỗi task phải được xác định một cách công khai thông qua một quy tắc chung.
  5. Độ khó của các task phải được tự động điều chỉnh hợp lý theo một quy tắc chung, sao cho mỗi coinbase transaction được tạo ra không quá nhanh mà cũng không quá chậm (nhanh quá thì lạm phát mà chậm quá thì giảm phát).
  6. Mỗi một task phải được tự động tăng độ khó mỗi khi có một solution hợp lệ được tìm ra cho nó. Như vậy “người đào” nào đến sau muốn đánh bật solution cũ thì phải giải lại task đó với mức độ khó cao hơn.
  7. Mỗi task có thể có vô số solution.
  8. Mỗi solution phải có một self-ID để phân biệt.
  9. Trong nội dung của mỗi solution phải đính kèm self-ID của task mà nó giải quyết.
  10. Ai đó có một solution hợp lệ của task A, nếu chỉ đơn thuần đổi self-ID của task A thành self-ID của task B, thì solution mới không thể giải được cho task B. Điều này là để chống lại việc xài đi xài lại cùng một solution cho nhiều task khác nhau.
  11. Những “người đào” có quyền chọn bất kỳ một task nào để giải. Dĩ nhiên, thông thường thì những task dễ nhất sẽ được chọn. Việc chọn task khó hơn để giải là một dấu hiệu cho thấy đang có gian lận. Với một task có độ khó cao ngút trời, thì gần như không thể giải và do đó không gian lận được.

Khi bạn đọc xong một đống những yêu cầu trên, bạn có cảm giác gì? Tôi hoàn toàn bế tắc, vậy nên khi hiểu ra thiết kế của Bitcoin, tôi không khỏi thán phục sự thiên tài của Satoshi Nakamoto.

Trong phần tới chúng ta sẽ bàn luận về thiết kế thực sự của Bitcoin nhằm giải quyết hết những vấn đề trên.

Advertisements

One thought on “Bitcoin – đồng tiền tự do (P.2)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s