Liệu SPV có hỗ trợ được hàng tỷ người dùng? Vấn đề mở rộng quy mô của nó. - DashVN

Latest

Tự do, công nghệ & đầu tư

Monday, September 4, 2017

Liệu SPV có hỗ trợ được hàng tỷ người dùng? Vấn đề mở rộng quy mô của nó.

Tác giả: Jameson Lopp. Anh là kỹ sư phần mềm tại BitGo, tác giả của statoshi.info và là sáng lập của bitcoinsig.com

Trong phần ý kiến này, Lopp đưa chúng ta đi sâu vào việc tuyên bố rằng việc loại bỏ giới hạn blockside là an toàn và thay vì dựa vào phương pháp SPV (Simplified Payment Verification)

Có một tuyên bố mới đang được duy trì trong cuộc tranh luận về mở rộng Bitcoin.

Chúng tôi nghe thấy nhiều người nói rằng có thể loại bỏ giới hạn về kích thước khối bởi vì Bitcoin có thể dễ dàng mở rộng kích thước khối rất lớn và như vậy nó có thể hỗ trợ hàng tỷ người dùng đồng thời với phương thức SPV. Giả sử, SPV là rất dễ mở rộng do lượng dữ liệu nhỏ mà phần mềm SPV lưu, gửi và nhận.
Hãy đào sâu vào tuyên bố này và xem xét nó từ nhiều góc nhìn khác nhau nhé.

SPV hoạt động như thế nào?

Satoshi đã miêu tả thiết kế bậc cao cho SPV trong bản cáo bạch, và khi đó nó vẫn chưa được thực hiện cho đến 2 năm sau đó và được thực hiện bởi Mike Hearn khi anh tạo ra BitcoinJ.
Việc triển khai SPV ban đầu khá ngây thơ - họ đã tải toàn bộ blockchain về, như vậy nó không hiệu quả hơn một full node (một nút mạng đầy đủ là một nút có chứa toàn bộ dữ liệu blockchain - ND) về mặt băng thông.

Bằng việc vứt bỏ đi các giao dịch không liên quan đến ví của khách hàng SPV thì điều đó đã có thể giúp tiết kiệm được dung lượng đĩa một cách đáng kể. Phải mất đến 18 tháng nữa thì BIP 37 mới được công bố, nó đã cung cấp một đặc tả cho Bloom lọc các giao dịch, mà nó dựa vào gốc của cây Merkle để chứng minh sự bao gồm của một giao dịch trong một khối như Satoshi đã mô tả. Điều này đã giảm băng thông đi rất nhiều.

Khi một máy khách SPV đồng bộ với mạng bitcoin, nó kết nối với một hoặc nhiều nút bitcoin đầy đủ (full node), xác định khối mới nhất ở đầu của chuỗi, sau đó yêu cầu tất cả các tiêu đề khối với lệnh "getheaders" cho các khối từ cuối và đồng bộ lên đến đầu chuỗi khối.

Nếu phần mềm SPV chỉ quan tâm đến các giao dịch cụ thể tương ứng với một ví, nó sẽ xây dựng bộ lọc Bloom dựa trên tất cả các địa chỉ mà ví có các khóa riêng (private keys) và gửi lệnh "filterload" đến các nút đầy đủ (full node) để chúng biết và chỉ trả lại các giao dịch khớp với bộ lọc.

Sau khi đồng bộ các tiêu đề khối và có thể tải một bộ lọc Bloom, phần mềm SPV gửi lệnh "getdata" để yêu cầu mỗi một khối bất kỳ (có thể được lọc) mà còn thiếu từ khi thấy lần cuối cùng khi chúng online, một cách tuần tự.

Một khi phần mềm đồng bộ, nếu nó vẫn kết nối với những nút đầy đủ (full node), nó sẽ chỉ nhận được thông báo "inv" cho các giao dịch phù hợp với bộ lọc Bloom đã tải.

Vấn đề mở rộng trên phần mềm SPV ở máy trạm

Từ quan điểm của phần mềm trên máy trạm, Bloom lọc là một phương tiện rất hiệu quả để tìm các giao dịch có liên quan trong blockchain, trong khi sử dụng tài nguyên tối thiểu về CPU, băng thông mạng và dung lượng lưu trữ.

Mỗi tiêu đề khối bitcoin chỉ là 80 byte, do đó, tại thời điểm viết bài này nó chỉ có 38 megabyte dữ liệu cho toàn bộ trên tám năm lịch sử của blockchain Bitcoin. Mỗi năm (khoảng 52.560 khối), chỉ thêm 4,2 megabyte, bất kể kích thước của khối trong blockchain có thế nào.

Cây Merkle được sử dụng để chứng minh sự bao gồm của một giao dịch trong một khối cũng có khả năng scale (mở rộng) rất tốt. Bởi vì mỗi "lớp" mới được thêm vào cây tăng gấp đôi tổng số "lá" nó có thể đại diện, bạn không cần một cây thật nhiều tầng để chứng minh một cách chặt chẽ sự bao gồm một giao dịch, ngay cả trong một khối với hàng triệu giao dịch.
Cấu trúc dữ liệu cây Merkle hiệu quả đến nỗi nó có thể đại diện cho 16 triệu giao dịch với độ sâu chỉ 24 - điều này đủ để đại diện cho một khối 8GB. Tuy nhiên, bằng chứng cây Merkle cho một giao dịch như vậy chỉ có kích thước dưới 1KB!
Theo cuốn Mastering Bitcoin của Andreas M. Antonopoulos
Rõ ràng là từ quan điểm của phần mềm máy trạm SPV thì mạng bitcoin có thể mở rộng thành các khối đa gigabyte và các phần mềm máy trạm SPV chỉ gặp rất ít khó khăn trong việc xử lý một lượng nhỏ dữ liệu cần thiết - ngay cả trên điện thoại di động có kết nối 3G.

Nhưng than ôi, việc mở rộng mạng bitcoin không đơn giản như vậy đâu.

Mở rộng trên phần mềm máy chủ SPV

Trong khi SPV cực kỳ hiệu quả với máy trạm, thì điều đó không đúng với trên máy chủ - đó là các nút đầy đủ (full node) mà các máy trạm có yêu cầu truy xuất dữ liệu. Phương pháp này thể hiện khả năng mở rộng rất kém với một số lý do như sau:

Các nút mạng phải xử lý một lượng dữ liệu rất lớn để trả về kết quả chỉ cho một máy trạm, và nó phải lặp lại công việc này cho mọi khối mà mỗi máy trạm yêu cầu. Khi đó việc truy xuất đĩa trở nên một nút thắt cổ chai.

Mỗi phần mềm SPV phải đồng bộ toàn bộ blockchain từ lần cuối cùng nó có liên lạc với mạng lưới, hoặc nếu nó cho rằng nó thiếu một vài giao dịch nào đó, nó sẽ phải quét lại toàn bộ blockchain từ ngày ví được khởi tạo. Trong trường hợp tệ nhất, tại thời điểm viết bài này có xấp xỉ 150 Gb dữ liệu. Một nút đầy đủ (full node) phải nạp từng khối một từ đĩa, lọc nó cho yêu cầu từ phần mềm máy trạm và trả lại kết qu

Vì blockchain là dạng sổ cái chỉ thêm vào, nên lượng dữ liệu này không bao giờ dừng lại chỉ ở con số như vậy. Nếu không có sự thay đổi lớn về thay đổi giao thức thì việc cắt tỉa blockchain là không thương thích với BIP 37 - nó đòi hỏi tất cả các khối phải sẵn sàng ở tất cả các nút đầy đủ (full node) mà có quảng cáo NODE_BLOOM.

Phần mềm máy trạm SPV BIP 37 có thể bị đánh lừa bởi sự bỏ sót. Để chống lại điều đó, phần mềm máy trạm SPV kết nối với nhiều nút (thường là 4 nút) dù điều đó cũng không phải là một đảm bảo rằng phần mềm SPV không bị tấn công bởi phương thức tấn công Sybil. Nó làm tăng tải trên mạng của các full node lên bốn lần.

Với mỗi kết nối của phần mềm máy trạm SPV mà được đồng bộ hóa với đầu của blockchain, mỗi khối đến và giao dịch phải được lọc riêng. Điều này liên quan đến một lượng thời gian không xử lý không nhỏ của CPU và nó phải được thực hiện riêng cho mỗi kết nối từ máy trạm SPV.

Nghiên cứu các con số

Tại thời điểm viết bài này thì có xấp xỉ 8300 full node đang chạy mà chấp nhận các kết nối, vào khoảng 8000 nút trong số đó có quảng cáo NODE_BLOOM và có thể phục vụ các yêu cầu từ phần mềm SPV. Nhưng bao các full node hiện nay có thể phục vụ được bao nhiêu SPV?

Cần phải có các full node thế nào để có thể phục vụ yêu cầu của hàng tỷ người dùng mỗi ngày và các block phải lớn thế nào để chứa được những giao dịch đó?
Theo Bitnodes
Bitcoin Core ngầm định cho phép tối đa 117 kết nối đến, và với 8000 full node thì nó có thể cho phép đến tối đa khoảng 936 ngàn kết nối trên toàn mạng. Tuy nhiên, đến nay thì phần lớn các kết nối đã được sử dụng rồi.

Ngầm định thì mỗi full node kết nối tới 8 full node khác. Và theo ước tính của Luke-Jr một thành viên trong nhóm lập trình của Bitcoin Core thì có khoảng 100 ngàn nút tại thời điểm khi bài này được viết, 92 ngàn trong số đó không tạo ra kết nối cho các phần mềm SPV. Việc này chiếm đến 800 ngàn kết nối chỉ dành cho các full node, chỉ để lại có 136 ngàn kết nối cho các phần mềm SPV.

Điều này dẫn đến kết luận rằng có khoảng 85 phần trăm các kết nối được sử dụng để relay dữ liệu cho các full node. (Nên chú ý rằng phương pháp ước lượng của Luke-Jr không thể xác định được thời gian mà các nút non-listening đang online, chắc chắn rằng ít nhất trong số đó thường xuyên ngắt kết nối và kết nối lại.)

Nút mạng của tôi cung cấp dữ liệu cho statoshi.info tính trung bình 100 full node (8 kết nối ra và 92 kết nối đến) và 25 phần mềm SPV. 80 phần trăm trong số kết nối được sử dụng bởi các full node.
Nếu chúng ta muốn đến 1 tỷ người dùng SPV có thể sử dụng hệ thống như thế này thì cần đến đủ một lượng full node với năng lực đầy đủ để phục vụ - kết nối mạng, tốc độ CPU, thông lượng lưu trữ, vân vân. Chúng ta hãy làm phép toán để làm rõ nhé?

Để tính toán yêu cầu cho việc scaling SPV, tôi sử dụng một số dự định bảo thủ rằng mỗi một tỷ người dùng SPV cần có:

- Gửi và nhận một giao dịch mỗi ngày.
- Đồng bộ ví của họ với dữ liệu mới nhất của blockchain mỗi ngày.
- Truy vấn 4 nút khác nhau khi đồng bộ để giảm nguy cơ bị lừa dối qua việc bỏ sót.

Một tỷ giao dịch mỗi ngày, nếu được phân phối đều (chắc chắn không thể) sẽ tương đương khoảng gần 7 triệu giao dịch mỗi block (mỗi block time của Bitcoin là 10 phút, nên 24 giờ sẽ có 144 block). Do khả năng mở rộng tuyệt vời của cây Merkle, nó chỉ cần 23 lần hash để chứng minh việc thêm một giao dịch vào trong một block: 736 bytes dữ liệu hash cộng với trung bình 500 byte cho mỗi giao dịch.

Thêm vào 12 KB dữ liệu cho block header mỗi ngày và mỗi phần mềm SPV cũng chỉ sử dụng khoảng 20 KB dữ liệu một ngày.

Tuy nhiên, một tỷ giao dịch mỗi ngày sinh ra 500 GB dữ liệu blockchain cho các full node lưu trữ và xử lý. Và mỗi thời điểm phần mềm SPV kết nối và truy vấn để tìm ra những giao dịch nào đó trong ví của nó trong quá khứ thì trong 4 nút mỗi nút phải đọc và lọc 500 GB dữ liệu.

Nhớ lại rằng hiện có khoảng 136 ngàn kết nối sẵn sàng cho các phần mềm SPV trên mạng lưới gồm 8000 nút phục vụ cho SPV. Nếu mỗi máy trạm SPV sử dụng 4 kết nối, thì chỉ có 34 ngàn máy trạm có thể đồng bộ với mạng lưới tại bất kỳ thời điểm nào. Nếu có nhiều người hơn online đồng thời thì những người dùng khác đang cố mở ví thì họ sẽ nhận được thông báo lỗi kết nối khi cố gắng đồng bộ dữ liệu blockchain mới nhất.

Như vậy, để mạng lưới hiện tại có thể phục vụ cho 1 tỷ người dùng SPV mà mỗi người chỉ đồng bộ một lần một ngày trong khi chỉ có 34 ngàn người có thể đồng bộ ở bất cứ thời điểm nào thì có đến 29 ngàn 400 “nhóm” người dùng phải kết nối, đồng bộ, ngừng kết nối: mỗi người dùng sẽ cần phải có thể đồng bộ dữ liệu của ngày hôm trước trong vòng ít hơn 3 giây.

Điều này đặt ra một vấn đề khó khăn bởi vì nó sẽ yêu cầu mỗi nút có khả năng đọc và lọc 167 GB dữ liệu trong mỗi giây cho mỗi máy trạm SPV một cách liên tục. Với 20 máy trạm SPV cho mỗi nút thì tương ứng với 3333 GB dữ liệu phải xử lý trong một giây. Tôi chưa thấy thiết bị lưu trữ nào có khả năng xử lý băng thông lớn đến như vậy. Có lẽ nó cần phải tạo ra một hệ thống RAID 0 khổng lồ gồm rất nhiều ổ cứng thể rắn cao cấp mà mỗi chiếc phải đạt tốc độ 600 MB/s.

Bạn cần phải có đến 5555 ổ cứng như vậy để đạt được băng thông đó. Giả sử mỗi ổ đĩa giá 400 USD tại thời điểm viết bài có dung lượng 1 TB - đủ lưu trữ dữ liệu cho 2 ngày về mặt lý thuyết. Khi đó bạn cần có một mảng các ổ đĩa đó cho mỗi 2 ngày. Như vậy bạn cần một mảng các đĩa mới cho mỗi 2 ngày, và nó tốn đến 2.2 triệu đô la - số tiền này lên đến hơn 400 triệu đô la để lưu trữ dữ liệu cho một năm để đáp ứng được băng thông đọc theo yêu cầu trên.

Tất nhiên chúng ta có thể xoay sở với các giả định này và tinh chỉnh các con số khác nhau. Liệu chúng ta có thể tạo ra một kịch bản mà chi phí cho mỗi nút hợp lý hơn?

Thử nhé:

Điều gì nếu chúng ta có 100 ngàn full node chạy trên các ổ cứng quay dung lượng lớn nhưng rẻ hơn thay vì sử dụng loại ổ cứng thể rắn và bằng cách nào đó thuyết phục rằng tất cả chúng để chấp nhận những kết nối từ các máy trạm SPV? Điều gì sẽ xảy ra nếu chúng ta tìm cách điều chỉnh để phần mềm full node có thể hỗ trợ đến 1000 máy trạm SPV?

Điều đó sẽ cho chúng ta 100 triệu kết nối cho các máy trạm SPV có thể hỗ trợ 25 triệu máy trạm SPV một cách đồng thời online trên mạng. Như vậy mỗi máy trạm SPV sẽ có 2160 giây mỗi ngày để đồng bộ với mạng lưới. Với mỗi full node để theo kịp nhu cầu nó cần duy trì tốc độ đọc ổn định là 231 MB/giây cho mỗi máy trạm SPV, điều đó sẽ tốn tới 231 GB/giây cho 1000 máy trạm SPV được kết nối.

Một ổ cứng quay tốc độ 7200 vòng phút có thể đọc tốc độ 220 MB/giây, thì để đạt được băng thông đó cần có mảng RAID 0 với hơn 1000 ổ đĩa.

Tại thời điểm viết bài này, bạn có thể mua một ổ cứng 10 TB với giá khoảng 400 USD thì mảng RAID các ổ cứng trị giá 400 ngàn USD cho phép bạn lưu trữ dữ liệu blockchain trong vòng 20 ngày - điều này sẽ giúp bạn tiết kiệm được 7.2 triệu USD để lưu trữ dữ liệu blockchain mỗi năm trong khi vẫn đạt được yêu cầu về tốc độ băng thông.
Bạn cần bổ sung ít nhất 2 hệ thống như thế này mỗi ngày
Cũng cần chú ý rằng không ai lại chạy một mảng RAID 0 với số lượng nhiều ổ cứng đến vậy vì nếu một ổ đĩa bị lỗi thì sẽ làm hỏng toàn bộ dữ liệu của mảng. Như vậy thì một mảng RAID khác có khả năng chịu lỗi tốt hơn có thể sẽ tốn kém hơn và tốc độ lại chậm hơn. Và như vậy sẽ là quá lạc quan nếu cho rằng có đến 100 ngàn tổ chức sẽ sẵn sàng chi hàng triệu dô la mỗi năm để chạy một full node.

Một điểm cần lưu ý khác là những ước tính bảo thủ này giả định rằng các máy trạm SPV sẽ phối hợp với nhau theo một cách nào đó để phân phối đều thời gian đồng bộ của chúng trong suốt mỗi ngày. Trong thực tế thì không có như vậy mà có những thời đỉnh điểm hoạt động hàng ngày hoặc hàng tuần - thông thường năng lực mạng lưới phải lớn hơn khá nhiều để đáp ứng được nhu cầu tại những thời gian cao điểm.

Nếu không thì sẽ có rất nhiều máy trạm SPV sẽ không thể đồng bộ được trong những thời gian cao điểm.

Thật thú vị việc thay đổi số lượng kết nối trên mỗi nút không ảnh hưởng đến lượng tải cho tổng thể một full node nào đó - nó vẫn cần phải xử lý cùng một lượng dữ liệu. Điều thực sự quan trọng trong phương trình này là tỷ số của các full node trên số máy trạm SPV. Và tất nhiên kích thước của các khối trong chuỗi mà các full node cần phải xử lý.

Kết quả cuối cùng dường như không tránh khỏi: chi phí vận hành một full node có khả năng phục vụ yêu cầu SPV của hàng tỷ giao dịch mỗi ngày sẽ là cực kỳ lớn.

Tìm kiếm mặt bằng chung

Đến thời điểm hiện nay thì rõ ràng rằng một tỷ giao dịch mỗi ngày làm cho chi phí vận hành một full node nằm ngoài khả năng của hầu hết mọi người trừ những công ty lớn nhất.

Nhưng, nếu chúng ta lật phép toán này lên đầu và thay vào đó tìm một công thức xác định chi phí để thêm tải cho mạng lưới bằng cách tăng băng thông cho các giao dịch on-chain?

Để mạng bitcoin hỗ trợ một lượng giao dịch nhất định trong mỗi giây (thêm năng lực cho 86400 người dùng mới mỗi ngày), chúng ta có thể tính toán yêu cầu cho băng thông đĩa cho mỗi nút như sau:
Điều này cho chúng ta băng thông đọc đĩa tối thiểu trên mỗi giây của một full node để có thể phục vụ nhu cầu của các máy trạm SPV. Với đặc tính hiện tại của mạng lưới và công nghệ hiện thời, chúng ta có thể ngoại suy chi phí ước tính cho việc vận hành nút bằng việc sử dụng băng thông đĩa như là nút cổ chai giả định. Lưu ý rằng chắc chắn sẽ có những hạn chế về tài nguyên khác và nó làm tăng chi phí vận hành full node.

Đối với các tính toán sau, tôi sử dụng những giả định này:

- Kích thước trung bình mỗi giao dịch = 500 bytes (theo statoshi.info).
- Tổng số người dùng SPV = số lượng giao dịch mỗi ngày.
- Số kết nối được sử dụng bởi máy trạm SPV = số lượng chuẩn là 4.
- Số lượng kết nối sẵn sàng cho các máy trạm SPV trên mỗi full node = số lượng đã tính toán trước đây là 20.
- Tổng số kết nối trên mạng lưới sẵn sàng cho các máy trạm SPV = số lượng đã tính toán trước đây là 136 ngàn.
- Chi phí cho băng thông và không gian lưu trữ cho ổ cứng = 400 USD cho ổ 10 Tb quay tốc độ 7200 vòng phút sử dụng RAID 0.
Chúng ta thấy rằng thông lượng đĩa khá hợp lý đến tận khi chúng ta vượt quá 100 giao dịch mỗi giây. Tại thời điểm này bạn bắt đầu phải mua nhiều ổ đĩa và chia chúng vào mảng RAID để đạt được yêu cầu về tốc độ.

Thật không may, yêu cầu về băng thông cho đĩa và chi phí vận hành full node tăng gấp 4 lần so với số lượng giao dịch trên mỗi giây. Chi phí nhanh chóng trở nên không thể kiểm soát được đối với hầu hết các tổ chức.

Để tiện tham khảo, hãy nhớ rằng Visa xử lý khoảng 2000 giao dịch mỗi giây. Tren bitcoin nó cần gần đĩa cứng gần 200 ngàn USD để đáp ứng được nhu cầu của SPV. Một điểm đáng chú ý nữa là biểu đồ này giữ cho số nút đủ lớn ở mức 8000 nút - trên thực tế số nút sẽ giảm xuống khi chi phí tăng, do đó yêu cầu về băng thông sẽ tăng và chi phí vận hành sẽ còn tăng lên nhanh hơn nữa nhiều.

Dường như có một lực kết hợp vào việc tập trung hoá các nút.
Như tôi đã kết luận trong bài “Làm thế nào để cứu mạng lưới nút của Bitcoin khỏi sự tập trung hoá”, một trong những vấn đề gốc rẽ của những tranh cãi xung quanh việc tăng kích thước block là chi phí vận hành của các nút. Các tính toán trên cho chúng ta một cái nhìn thoáng qua về sự phức tạp của việc tính toán chi phi vận hành nút vì có quá nhiều biến số liên quan - những tính toán này đã giữ hầu hết các biến số không thay đổi và chỉ tập trung vào chi phí băng thông cho đĩa.

Một cuộc thăm dò (không khoa học) mà tôi đã tiến hành năm ngoái cho thấy 98% các nhà vận hành nút không trả quá 100 USD mỗi tháng để chạy một nút, ngay cả khi họ đầu tư nhiều vào bitcoin. Tôi sẵn sàng đặt cược rằng việc tăng lượng giao dịch on-chain một bậc sẽ làm giảm mất phần lớn lượng full node, trong khi tăng hai bậc sẽ làm mất đến 90% trở lên các nút.

Tôi tin rằng sẽ an toàn hơn nếu giả sử rằng chỉ có rất ít tổ chức sẵn lòng tham gia giải quyết vấn đề khó khăn trong việc xây dựng mảng RAID để chạy một full node. Nếu trong hoàn cảnh này, thật không thể biện hộ rằng việc tăng như vậy là tốt cho những người dùng bình thường, vì sẽ không có đủ thông lượng đĩa hoặc kết nối để phục vụ nhu cầu SPV.

Những nhược điểm khác của SPV

SPV thật tuyệt vời cho người dùng cuối không yêu cầu bảo mật hoặc sự riêng tư của một nút xác nhận đầy đủ. Tuy nhiên, có rất nhiều lý do có thể được coi là một trở ngại cho sự tiến bộ cho một mạng bitcoin chủ yếu-SPV, bất kể khả năng mở rộng của nó.

SPV dựa vào các giả định chính dẫn đến khả năng bảo mật và sự riêng tư thấp hơn một nút xác nhận đầy đủ (fullnode):

  1. Phần mềm máy trạm SPV tin tưởng vào các thợ mỏ để xác nhận chính xác và thi hành các quy tắc của bitcoin; chúng cho rằng blockchain với proof of work dài nhất là một chuỗi hợp lệ. Bạn có thể tìm hiểu về sự khác nhau giữa SPV và các mô hình bảo mật nút đầy đủ trong bài viết này.
  2. Phần mềm SPV dựa vào giả định rằng các nút đầy đủ sẽ không nói dối bằng cách bỏ sót. Một nút đầy đủ không thể nói dối và nói rằng một giao dịch tồn tại trong một khối khi nó không thực sự tồn tại, nhưng nó có thể nói dối bằng cách nói rằng một giao dịch đã tồn tại trong một khối đã không xảy ra.
  3. Bởi vì phần mềm máy trạm SPV phấn đấu vì tính hiệu quả, chúng chỉ yêu cầu dữ liệu cho các giao dịch thuộc về nó. Do vậy kết quả là nó phải hy sinh rất nhiều về sự riêng tư.

Thú vị rằng, đồng tác giả của BIP 37, ông Matt Corallo đã tiếc rằng đã tạo ra nó:
Một vấn đề lớn hiện nay đối với sự riêng tư của người dùng trong hệ thống là các bộ lọc BIP37 SPV bloom. Tôi xin lỗi, tôi đã tạo ra nó.
Bộ lọc BIP 37 trên phần mềm máy trạm SPV về cơ bản không có sự riêng tư, ngay cả khi sử dụng các tỷ lệ sai lệch cao bất thường. Jonas Nick (một kỹ sư an ninh ở Blockstream) phát hiện ra rằng nếu dùng một khóa công khai, ông ta có thể xác định được 70% các địa chỉ khác thuộc cùng một chiếc ví đó.
Bạn có thể tránh vấn đề riêng tư kém của SPV bằng việc tách các bộ lọc Bloom trong nhiều các nút ngang hàng khác nhau, mặc dù điều đó sẽ làm vấn đề mở rộng của SPV càng trở nên tồi tệ hơn bằng việc chất thêm tải cho các full node.

BIP 37 cũng dễ tổn thương với những tấn công từ chối dịch vụ. Mã demo có sẵn ở đây có thể làm tê liệt các nút (full node) bằng cách đưa ra rất nhiều yêu cầu kiểm kê nhanh và truy vấn thông qua những bộ lọc được xây dựng đặc biệt làm cho liên tục tìm kiếm trên đĩa và sử dụng nhiều tài nguyên CPU.

Tác giả của demo về tấn công, Core Developer của Bitcoin, Peter Todd, giải thích rằng:
Vấn đề cơ bản là bạn có thể tiêu tốn một lượng băng thông I / O đĩa không cân xứng với băng thông mạng rất ít.
Thậm chí đến ngày nay vẫn có những cảnh báo không đúng rằng Satoshi đã mô tả trong cáo bạch đã không được thực hiện. Thực ra, những nỗ lực nghiên cứu trong lĩnh vực này đã cho thấy rằng thậm chí đã không thể thực hiện được những cảnh báo gian lận nhẹ.

Ví dụ: cảnh báo gian lận chỉ hoạt động nếu bạn thực sự có được dữ liệu cần thiết để chứng minh gian lận - nếu một thợ mỏ không cung cấp dữ liệu đó, cảnh báo gian lận không thể được tạo ra. Như vậy, các phần mềm máy trạm SPV không có mức độ an ninh mà Satoshi hình dung là chúng sẽ có.

Từ quan điểm cấp cao, một thế giới bao gồm hầu hết các nút SPV tạo ra những đồng thuận thay đổi như tổng số coin hoặc thậm chí chỉnh sửa sổ cái dễ dàng hơn nhiều. Càng ít các nút đầy đủ (full node) có nghĩa là việc đồng thuận càng có tính tập trung hơn và do đó ít phản đối hơn với việc thay đổi các quy tắc đồng thuận. Một số người có thể xem xét rằng đó là một tính năng; hầu hết chắc chắn xem đó là một lỗ hổng.

Những cải tiến tiềm năng

Bảo mật SPV và khả năng mở rộng có thể được cải thiện bằng nhiều cách khác nhau thông qua các bằng chứng gian lận, gợi ý gian lận, các bằng chứng đầu vào, bằng chứng chi tiêu, v.v ... Nhưng theo như tôi biết, không có gì trong số này đã qua giai đoạn ý tưởng, càng ít hơn cho giai đoạn sẵn sàng triển khai.

Bộ lọc Bloom cam kết có thể cải thiện tính riêng tư, nhưng nó phải đánh đổi cho tính hữu ích giữa kích thước của bộ lọc với tỷ lệ sai sót: quá thô có nghĩa là các trạm phải download quá nhiều khối sai, quá mịn có nghĩa là các bộ lọc sẽ trở nên rất khổng lồ và rất lớn để có thể tải bằng các phần mềm máy trạm SPV.

Sẽ giảm tải cho thông lượng đĩa trên full node, nhưng việc đánh đổi sẽ là tăng băng thông cho cả phần mềm SPV trên máy trạm và trên full node bởi vì toàn bộ các block sẽ phải truyền tải trên mạng.

Đề xuất gần đây về bộ lọc nhỏ gọn ở máy trạm đã loại bỏ được vấn đề về sự riêng tư, nhưng nó đòi hỏi phải tải xuống toàn bộ các khối nếu có sự trùng khớp với bộ lọc (mặc dù không cần thiết phải qua mạng ngang hàng-p2p)

Cam kết UTXO có thể cho phép các phần mềm máy trạm SPV đồng bộ thiết lập UTXO hiện tại của họ và số dư của ví mà không yêu cầu full node để quét toàn bộ blockchain. Thay vào đó, nó sẽ cung cấp bằng chứng về UTXO hiện có.

Có thể bảo vệ chống lại các cuộc tấn công DoS của Bloom bằng cách yêu cầu các khách hàng SPV đệ trình proof of work (không thể dùng được trên thiết bị sử dụng pin như điện thoại) hoặc micropayments theo kênh, nhưng cũng không đưa ra một giải pháp đơn giản.

Việc yêu cầu đọc đĩa cho các full node có thể được giảm bằng một số cách như cải thiện việc lập chỉ mục dữ liệu và xử lý theo nhóm các yêu cầu từ các phần mềm máy trạm SPV.

Ryan X Charles chỉ ra trong nhận xét dưới đây rằng việc sử dụng giao thức thanh toán BIP70 để nói trực tiếp với ai đó về UTXO ID của giao dịch mà bạn gửi và điều đó làm họ không cần phải sử dụng các bộ lọc bloom vì có thể yêu cầu dữ liệu trực tiếp từ full node. Điều này cực kỳ hiệu quả nếu bạn sẵn lòng đánh đổi tính riêng tư.

Có thể nói rằng có nhiều chỗ cho cải tiến - rất nhiều thử thách cần phải vượt qua để cải thiện khả năng mở rộng trên chuỗi (on-chain scalability).

Những giải pháp mở rộng phù hợp

Nếu chúng ta bỏ qua vô số các vấn đề khác phức tạp với việc mở rộng các kích thước khối lớn hơn như độ trễ lan truyền khối, thiết lập UTXO, thời gian đồng bộ hóa blockchain ban đầu và bảo mật và sự riêng tư, thì về mặt kỹ thuật có thể mở rộng quy mô bitcoin đến một tỷ người dùng hàng ngày nếu có các đơn vị sẵn sàng đầu tư các nguồn lực quan trọng để phát triển các cải tiến phần mềm và vận hành cơ sở hạ tầng cần thiết (hiện tại các coin đều không có nguồn lực đầu tư này ngoài Dash - ND).

Có vẻ như không chắc chắn rằng bitcoin sẽ tiến hoá hữu cơ theo cách đó, tuy nhiên, bởi vì có nhiều cách hiệu quả hơn để mở rộng hệ thống. Hiệu quả nhất là một hình thức mở rộng đã được sử dụng: hợp nhất xung quanh các nhà cung cấp API tập trung. Điều này thì phải có sự tin tưởng rất lớn và sự đánh đổi tính riêng tư khi sử dụng các phương pháp này, nhưng nhiều tương tác như vậy liên quan đến hợp đồng thỏa thuận và điều đó giảm nhẹ một số nguy cơ.

Về khía cạnh mở rộng theo cách không cần tin cậy, các giao thức lớp 2 như Lightning đề nghị cách mở rộng hiệu quả hơn rất nhiều bởi lượng dữ liệu lớn được truyền tải chỉ thông qua số lượng nhỏ các đối tác một cách trực tiếp liên quan đến các giao dịch không trên chuỗi. Bạn có thể nghĩ về điều đó như là sự khác biệt giữa việc quảng bá đến tất cả qua giao thức lớp ethernet so với phương thức định tuyến lớp IP - mạng Internet đã không thể mở rộng mà không có sự định tuyến và điều đó cũng tương tự đối với tiền Internet.

Mặc dù cách tiếp cận mở rộng quy mô này phức tạp hơn nhiều so với quy mô tập trung truyền thống và sẽ phải vượt qua được một số thách thức độc nhất, việc đầu tư trực tiếp các nguồn lực để nghiên cứu và phát triển các giao thức định tuyến này sẽ trả chi phí rất lớn trong thời gian dài, cũng giống như giảm tải nó cũng cần chia sẻ cho toàn bộ mạng lưới tăng dần theo độ lớn của nó.

Có rất nhiều lựa chọn ở đó để chúng ta có thể khám phá:

– Centralized custodial schemes with perfect privacy that use Chaum tokens such as HashCash.

– Centralized non-custodial zero knowledge proof systems such as TumbleBit.

– Federated (semi-trusted multisignature) sidechains.

– Miner-secured (semi-trusted) drivechains.

Tôi vẫn tin rằng trong dài hạn, bitcoin sẽ cần nhiều khối lớn hơn.

Nhưng hãy kiên nhẫn và xử lý khéo bằng cách cố gắng nâng cấp hệ thống một cách hiệu quả nhất có thể trong khi duy trì tính bảo mật và tính riêng tư của nó.

Một PayPal phi tập trung, có thể kiểm soát được sẽ hữu ích nếu nó hoạt động theo quan điểm của người dùng bình thường, nhưng nó sẽ không cung cấp mức độ chủ quyền tài chính tối cao mà các nhà bitcoin ngày nay vẫn thích.

Xin cám ơn Matt Corallo, Mark Erhardt và Peter Todd để xem xét và cung cấp phản hồi cho bài viết này.

Biên dịch từ nguồn: Coindesk.com

No comments:

Post a Comment