110 lý do tại sao BIP 110 là một ý tưởng tồi

@saylor
TIẾNG ANH2 ngày trước · 18 thg 7, 2026
1.2M
3.9K
694
729
909

TL;DR

Michael Saylor lập luận phản đối BIP 110, một đề xuất soft fork của Bitcoin, với lý do rằng nó làm suy yếu tính trung lập của giao thức và tạo ra tiền lệ nguy hiểm khi sử dụng các quy tắc đồng thuận để lọc các loại dữ liệu cụ thể.

Một lập luận ủng hộ các quy tắc trung lập, sự đồng thuận vững chắc, thị trường mở và sự đổi mới không cần xin phép

Nhiều người theo chủ nghĩa Bitcoin mà tôi tôn trọng ủng hộ BIP 110. Họ muốn giữ cho việc xác thực luôn dễ tiếp cận, bảo vệ người vận hành nút khỏi các chi phí và nội dung không mong muốn, duy trì các khoản thanh toán giá cả phải chăng, và giữ cho Bitcoin tập trung vào tiền tệ vững chắc thay vì lưu trữ dữ liệu đa dụng. Đó là những mối quan tâm nghiêm túc. Tôi chia sẻ các mục tiêu. Tôi không đồng ý về giải pháp. (GitHub

Bài viết này phê bình đề xuất, chứ không phải những người đứng sau nó. Tôi giả định thiện chí. Bitcoin mạnh nhất khi chúng ta có thể bất đồng quan điểm mạnh mẽ mà không nhầm lẫn đồng minh với kẻ thù.

Đây cũng không phải là sự bảo vệ cho mọi inscription, token, tệp tin hay ứng dụng. Một số có thể là phù phiếm, có hại hoặc gian lận. Câu hỏi hẹp hơn: một tranh chấp về việc sử dụng các giao dịch hiện đang hợp lệ, trả phí có nên được giải quyết bằng cách thay đổi đồng thuận hay không?

Không phải mọi lý do dưới đây đều có trọng lượng ngang nhau, và một số lý do củng cố lẫn nhau. Lập luận mang tính tích lũy.

Điều Gì BIP 110 Đề Xuất

Bài viết này đề cập đến BIP 110 phiên bản 1.0.0, "Bản Soft Fork Tạm thời Giảm Dữ liệu," được nâng lên trạng thái Complete vào ngày 25 tháng 6 năm 2026. Theo BIP 3, Complete có nghĩa là các tác giả đã hoàn thành công việc đã lên kế hoạch và khuyến nghị áp dụng. Nó không có nghĩa là Bitcoin đã áp dụng đề xuất hoặc cộng đồng đã đạt được đồng thuận. Kho lưu trữ BIPs nêu rõ rằng việc xuất bản không xác lập rằng một đề xuất là tốt, có sự đồng thuận của cộng đồng, hoặc sắp được áp dụng. (GitHub

Trong khoảng thời gian hoạt động khoảng một năm, BIP 110 sẽ thêm bảy hạn chế đồng thuận. Nó sẽ giới hạn scriptPubKey mới ở 34 byte, với ngoại lệ 83 byte cho OP_RETURN; giới hạn nhiều payload được đẩy và các mục witness của đối số script ở 256 byte; cấm chi tiêu các phiên bản witness và Tapleaf chưa được xác định trong khi vẫn cho phép tạo ra các đầu ra như vậy; cấm phụ lục Taproot; giới hạn khối điều khiển Taproot ở 257 byte; từ chối Tapscript chứa opcode OP_SUCCESSx; và từ chối thực thi Tapscript của OP_IF hoặc OP_NOTIF. (GitHub

Đề xuất bảo lưu các đầu ra giao dịch chưa tiêu được tạo ra trước khi kích hoạt. Đó là một biện pháp bảo vệ quan trọng. Tôi không tuyên bố rằng BIP 110 tịch thu rộng rãi bitcoin hiện có. Sự phản đối của tôi hẹp hơn: nó loại bỏ theo hướng tương lai chức năng giao dịch hiện đang hợp lệ, có thể ảnh hưởng đến các quy trình làm việc ký trước hiếm gặp kéo dài qua quá trình kích hoạt, làm giảm tính linh hoạt kỹ thuật, và thiết lập một tiền lệ cho việc sử dụng các hạn chế đồng thuận để ngăn cản một loại hình sử dụng hợp lệ khác. (GitHub

BIP 110 cũng đề xuất một triển khai BIP 9 đã được sửa đổi. Nó sử dụng ngưỡng tín hiệu thợ đào 55 phần trăm, so với ngưỡng 95 phần trăm được chỉ định trong BIP 9; loại bỏ thời gian chờ thông thường và trạng thái FAILED; thêm một giai đoạn tín hiệu bắt buộc; đảm bảo khóa chặt trên chuỗi thực thi không muộn hơn một độ cao được chỉ định; và thêm trạng thái EXPIRED mới sau 52,416 khối hoạt động. (GitHub

Giống như bất kỳ soft fork nào, BIP 110 không bị áp đặt bởi một cơ quan trung ương. Người dùng chọn phần mềm và quy tắc nào để thực thi. Rủi ro phát sinh khi những người tham gia có ý nghĩa kinh tế thực thi các quy tắc khác nhau về cơ bản, tạo ra áp lực, sự không chắc chắn hoặc một sự chia tách chuỗi.

Các tác giả cung cấp một triển khai tham chiếu, các vector kiểm thử, một cơ sở lý luận chi tiết và một cuộc thảo luận thẳng thắn về các đánh đổi. Đó là những điểm mạnh thực chất của tài liệu. Đề xuất lập luận rằng tính cấp bách và thời hạn tạm thời biện minh cho ngưỡng thấp hơn và các hạn chế đơn giản, trực tiếp có chủ đích. Tôi tôn trọng mối quan tâm và công việc. Tôi không đồng ý với phép tính rủi ro. (GitHub

I. Tính Trung Lập và Các Nguyên Tắc Cơ Bản

1. Đồng thuận là can thiệp mạnh mẽ nhất của Bitcoin. Một soft fork làm cho một số khối từng hợp lệ theo các quy tắc trước đó trở nên không hợp lệ đối với các nút đã nâng cấp. Sức mạnh đó nên được dành riêng cho các lỗi rõ ràng, nghiêm trọng và được hiểu rộng rãi.

2. Nó không phải là sửa chữa cho một lỗi đồng thuận đã được xác lập. BIP 110 không sửa lỗi lạm phát, xác thực chữ ký, chi tiêu gấp đôi hoặc một lỗi nghiêm trọng đã biết. Nó giải quyết một ngoại tác và trường hợp sử dụng đang tranh chấp, vì vậy gánh nặng chứng minh phải đặc biệt cao.

3. Nó nâng một phán đoán đang tranh chấp lên thành luật giao thức. Đề xuất di chuyển một tranh chấp về việc sử dụng hợp pháp và các ngoại tác từ chính sách chuyển tiếp, chính sách khai thác và thị trường vào tính hợp lệ đồng thuận.

4. Bitcoin không thể đọc được ý định. Mạng lưới không thể biết liệu các byte đại diện cho một hình ảnh, một bằng chứng, một hợp đồng, siêu dữ liệu, một bản ghi xác thực hay một ứng dụng trong tương lai.

5. Các proxy cấu trúc tạo ra rủi ro tài sản thế chấp. Bởi vì không thể biết được ý định, đề xuất hạn chế các hình thức kỹ thuật có thể phục vụ cả mục đích không được ưa chuộng và hợp pháp.

6. Một thông điệp xã hội không phải là căn cứ đủ cho một thay đổi đồng thuận. Thông số kỹ thuật coi việc kích hoạt như một cách để truyền đạt rằng việc lưu trữ dữ liệu là không được hoan nghênh. Đồng thuận nên được thay đổi vì các lý do kỹ thuật hoặc tiền tệ thuyết phục, không phải chủ yếu để thể hiện sự không tán thành. (GitHub

7. Sự không tán thành không phải là sự vô hiệu. Một giao dịch có thể là tầm thường, đầu cơ, xúc phạm hoặc lãng phí và vẫn tuân theo các quy tắc và trả phí cần thiết để được đưa vào.

8. Nó thu hẹp quyền tự do kinh tế trong tương lai trên chuỗi BIP 110. Các UTXO trước khi kích hoạt được bảo lưu, nhưng người dùng tạo UTXO trong thời gian hoạt động sẽ có ít cách hợp lệ hơn để cấu trúc và chi tiêu chúng so với đồng thuận hiện tại.

9. Các hệ thống không cần xin phép phải chịu đựng thử nghiệm chưa được chấp thuận. Yêu cầu những người đổi mới chứng minh việc sử dụng của họ là xứng đáng trước khi xây dựng sẽ đảo ngược ý nghĩa của sự đổi mới không cần xin phép.

10. Nó làm đảo lộn chủ nghĩa bảo thủ giao thức. Chủ nghĩa bảo thủ ở lớp cơ sở nên có nghĩa là miễn cưỡng thay đổi đồng thuận, không phải là sự háo hức thay đổi đồng thuận để ủng hộ một triết lý sử dụng bảo thủ.

II. Gánh Nặng Chứng Minh Chưa Được Đáp Ứng

11. "Spam" không phải là một nguyên thủy đồng thuận. Không có opcode nào có thể phân biệt spam với tiện ích. Những nhãn mác đó phát sinh từ phán đoán của con người.

12. "Tiền tệ" và "phi tiền tệ" không thể tách rời rõ ràng. Một kênh thanh toán, bằng chứng dự trữ, chính sách lưu ký, hợp đồng thông minh hoặc cam kết thanh toán vừa là hoạt động tài chính vừa là dữ liệu.

13. Các trường hợp sử dụng đã biết không phải là toàn bộ không gian thiết kế. Đề xuất nói rằng nó bảo tồn tất cả các trường hợp sử dụng tiền tệ đã biết. Sự đổi mới được định nghĩa bởi những gì chưa được biết đến.

14. Bản thân BIP không định lượng gánh nặng nút mà nó sẽ loại bỏ. Nó mô tả các chi phí nhưng không ước tính băng thông, lưu trữ, tải xác thực, ngưỡng phần cứng có liên quan hoặc số lượng người vận hành nút có khả năng tăng hoặc giảm.

15. Nó không định lượng lợi ích phi tập trung hóa. Tuyên bố rằng BIP 110 sẽ cải thiện phi tập trung hóa không đi kèm với một mô hình hoặc mục tiêu có thể đo lường được.

16. Nó không định lượng sự giảm nhẹ thanh toán. Nó không ước tính phí giao dịch sẽ giảm bao nhiêu, trong bao lâu, hoặc bao nhiêu người dùng thanh toán sẽ được hưởng lợi.

17. Nó kết hợp các chi phí riêng biệt vào một chẩn đoán. Sự tăng trưởng trạng thái UTXO, băng thông đồng bộ ban đầu, lưu trữ lưu trữ, gánh nặng chuyển tiếp và thời gian xác thực có các nguyên nhân khác nhau và có thể yêu cầu các biện pháp khắc phục khác nhau.

18. Tính cấp bách được khẳng định hơn là được xác định về mặt vận hành. Đề xuất gọi tình hình là khẩn cấp và một cuộc khủng hoảng, nhưng không cung cấp ngưỡng khách quan nào mà tại đó can thiệp đồng thuận trở nên cần thiết.

19. Một giới hạn chính sách chuyển tiếp lịch sử không phải là bằng chứng cho một giới hạn đồng thuận tối ưu. Mặc định 83 byte có thể là một chính sách hữu ích mà không trở thành một quy tắc tính hợp lệ của khối vượt thời gian.

20. Giới hạn 256 byte là heuristic. Cơ sở lý luận liên quan nó một phần đến kích thước hình ảnh nén và số nguyên mật mã lớn, nhưng không xác lập 256 byte là ranh giới tối ưu giữa an toàn và đổi mới. (GitHub

III. Phạm Vi Kỹ Thuật Quá Rộng

21. Bảy thay đổi đồng thuận riêng biệt được gộp lại với nhau. Những người tham gia không thể ủng hộ một hạn chế và bác bỏ một hạn chế khác. Họ phải chấp nhận hoặc từ chối toàn bộ gói.

22. Mối quan tâm kỹ thuật mạnh nhất được gộp chung với các hạn chế không liên quan. Các scriptPubKey lớn có thể làm tăng chi phí trạng thái UTXO và xác thực. Nếu điều đó tạo ra một nguy cơ có thể đo lường được, nó xứng đáng có một đề xuất phạm vi hẹp riêng, không phải sự hỗ trợ tự động cho sáu hạn chế bổ sung. (GitHub

23. Chính sách OP_RETURN 83 byte trở thành đồng thuận. Điều đó chuyển đổi một tùy chọn chuyển tiếp và khai thác có thể cấu hình thành một quy tắc tính hợp lệ của khối.

24. Các giới hạn 256 byte hạn chế các nguyên thủy chung. Chúng nhắm mục tiêu lưu trữ dữ liệu bằng cách hạn chế các lớp rộng của payload được đẩy và các mục witness của đối số script.

25. Việc chi tiêu các phiên bản witness và Tapleaf chưa được xác định sẽ bị vô hiệu hóa. Những không gian này ngày nay không được sử dụng một phần vì chúng được dành riêng cho các nâng cấp trong tương lai.

26. Phụ lục Taproot sẽ bị vô hiệu hóa. BIP 341 dành riêng phụ lục cho các phần mở rộng trong tương lai. Ngay cả khi người dùng không nên sử dụng nó trước khi ý nghĩa của nó được xác định, việc đóng một đường dẫn nâng cấp có chủ đích nên yêu cầu sự biện minh đặc biệt. (GitHub

27. Độ sâu của Taptree sẽ bị giảm. Giới hạn 257 byte cho khối điều khiển giới hạn các đường dẫn script được tiết lộ ở bảy cấp độ và có thể hạn chế các cây script phức tạp.

28. OP_SUCCESSx sẽ bị vô hiệu hóa ngay cả trong các nhánh không được thực thi. BIP 342 đã tạo các opcode này như các móc nâng cấp sạch sẽ cho các soft fork trong tương lai. (GitHub

29. OP_IF và OP_NOTIF được thực thi sẽ bị cấm trong Tapscript. Các tác giả coi chúng là dư thừa và thường bị lạm dụng, nhưng cũng thừa nhận các sử dụng thử nghiệm và các hiệu quả Miniscript có thể có.

30. Đề xuất công khai chấp nhận sự thô bạo để đổi lấy tốc độ. Cơ sở lý luận của nó nói rằng một cách tiếp cận cân bằng hơn sẽ đòi hỏi nhiều phát triển và xem xét hơn, vì vậy nó chọn các hạn chế đơn giản hơn nhằm triển khai nhanh hơn. Tính cấp bách không phải là sự thay thế cho độ chính xác trong mã đồng thuận. (GitHub

IV. Nó Hy Sinh Khả Năng Tương Thích và Tính Linh Hoạt Tương Lai

31. Nó đóng một số đường dẫn nâng cấp cùng một lúc. Phụ lục, các phiên bản witness trong tương lai, các phiên bản Tapleaf trong tương lai và OP_SUCCESSx đều là một phần của không gian thiết kế dành riêng của Bitcoin. (GitHub

32. Dành riêng không có nghĩa là vô dụng. Nó có nghĩa là các nhà thiết kế trước đó đã cố tình bảo tồn giá trị lựa chọn cho các nhu cầu chưa xuất hiện.

33. Việc đóng cửa một năm vẫn có thể làm gián đoạn tiến độ phát triển. Các tác giả kỳ vọng các soft fork trong tương lai sẽ đòi hỏi hơn một năm phối hợp, nhưng đó là một ước tính, không phải là một sự đảm bảo.

34. Nó có thể làm phức tạp các thiết kế kiểu BitVM. Thông số kỹ thuật thừa nhận rằng giới hạn khối điều khiển có thể cản trở các hợp đồng off-chain tiên tiến.

35. Nó có thể ảnh hưởng đến các Tapleaf do Miniscript tạo ra. Đề xuất thừa nhận rằng một số đầu ra của trình biên dịch có thể chứa OP_IF và sẽ cần điều chỉnh.

36. Nó yêu cầu thay đổi trong các công cụ ví bị ảnh hưởng. Phần tương thích ngược nêu rõ rằng trình biên dịch Miniscript sẽ cần sửa đổi trong khi các quy tắc đang hoạt động.

37. Nó tạo ra một rủi ro truy cập quỹ hẹp nhưng được thừa nhận. BIP thẳng thắn xác định các kịch bản Taproot ký trước hiếm gặp trong đó các UTXO sau khi kích hoạt có thể bị đóng băng hoặc chi tiêu bất ngờ.

38. Bảo lưu là có giá trị nhưng không phải là cách ly hoàn toàn. Các UTXO trước khi kích hoạt được bảo vệ, nhưng các quy trình làm việc tạo ra hoặc chi tiêu các đầu ra bị ảnh hưởng trong quá trình triển khai vẫn có thể gặp các ràng buộc mới.

39. Người dùng được khuyên nên di chuyển các quỹ có khả năng bị ảnh hưởng. Một đề xuất yêu cầu ngay cả một lớp người dùng hẹp phải di chuyển không phải là một bộ lọc không tốn kém.

40. "Không có trường hợp sử dụng nào được biết đến" không phải là bằng chứng an toàn. Các hệ thống riêng tư, hợp đồng chưa được công bố, ví thử nghiệm và giao thức trong tương lai không thể quan sát đầy đủ. (GitHub

V. Các Quy Tắc Đồng Thuận Tạm Thời Vẫn Tạo Ra Sự Phức Tạp Thực Sự

41. Mã đồng thuận tạm thời vẫn là mã đồng thuận. Nó phải được đặc tả, triển khai, xem xét, kiểm thử, triển khai, giám sát và sau đó loại bỏ.

42. Bảo lưu làm cho tính hợp lệ phụ thuộc vào lịch sử. Cùng một cấu trúc chi tiêu có thể được xử lý khác nhau tùy thuộc vào thời điểm UTXO được tạo ra.

43. Các quy tắc phụ thuộc vào lịch sử làm tăng độ phức tạp triển khai. Mọi triển khai phải xác định độ cao tạo UTXO có liên quan và áp dụng các miễn trừ giống hệt nhau.

44. Kích hoạt tạo ra một ranh giới quan trọng. Phần mềm và các tác nhân kinh tế phải đồng ý về thời điểm các hạn chế mới bắt đầu.

45. Hết hạn tạo ra một ranh giới khác. Họ cũng phải đồng ý về thời điểm các hạn chế kết thúc và hành vi bị hạn chế trước đó trở nên hợp lệ trở lại.

46. BIP 110 thêm một trạng thái EXPIRED mới. Điều đó mở rộng máy trạng thái triển khai quen thuộc với hành vi đồng thuận mới.

47. Nó loại bỏ kết quả FAILED thông thường. Việc triển khai được đề xuất không thể chỉ đơn giản là hết thời gian theo cách BIP 9 thông thường.

48. Nó tạo ra một số cửa sổ phối hợp. Tín hiệu tự nguyện, tín hiệu bắt buộc, khóa chặt, kích hoạt và hết hạn mỗi cái đều tạo ra cơ hội cho sự khác biệt. (GitHub

49. Các quy tắc tạm thời có thể để lại các hiện vật vĩnh viễn. Mã ví, quy trình vận hành, hợp đồng và các kiểm soát rủi ro thể chế có thể cần thay đổi tồn tại lâu hơn thời gian triển khai.

50. Càng nhiều nhánh đồng thuận càng có nhiều bề mặt lỗi. Các vector kiểm thử làm giảm rủi ro đã biết, nhưng không thể liệt kê mọi tương tác riêng tư hoặc tương lai.

VI. Các Tác Động Kinh Tế và An Ninh Là Không Chắc Chắn

51. Ngoại tác nút là có thật nhưng không đồng nhất. Mọi nút xác thực đầy đủ phải tải xuống và xác minh các khối, trong khi các nút đã cắt tỉa có thể loại bỏ dữ liệu khối thô cũ và giới hạn lưu trữ lịch sử. Các chi phí liên quan nên được đo lường riêng biệt. (Bitcoin Core

52. Vấn đề người nhận phí không phải là duy nhất đối với các giao dịch dữ liệu. Thợ đào thu phí trong khi người xác thực chịu một số chi phí cho mọi giao dịch. Mức độ có thể khác nhau, nhưng cấu trúc cơ bản là phổ biến.

53. Chi phí kỹ thuật nên được đo lường trực tiếp. Đối với một lượng dữ liệu và công việc xác thực nhất định, chi phí tài nguyên phát sinh từ byte, trạng thái, tính toán và băng thông, không phải từ việc liệu người quan sát có chấp thuận mục đích của giao dịch hay không.

54. BIP 110 không thể loại bỏ việc nhúng dữ liệu. Thông số kỹ thuật thừa nhận rằng người dùng có thể chia dữ liệu thành các phần nhỏ hơn hoặc ngụy trang nó trong các cấu trúc được phép. (GitHub

55. Trốn tránh có thể làm cho các giao dịch kém hiệu quả hơn. Các mã hóa bị phân mảnh hoặc che giấu có thể tiêu thụ nhiều cấu trúc hơn và làm phức tạp phân tích mà không loại bỏ nhu cầu cơ bản.

56. Hiệu ứng phí là không rõ ràng. Đàn áp một loại hình sử dụng có thể làm giảm phí thanh toán, giảm tổng doanh thu phí, chuyển nhu cầu sang các mã hóa khác hoặc tạo ra một số kết hợp của ba điều trên.

57. Doanh thu của thợ đào trở nên quan trọng hơn khi trợ cấp giảm dần. Phí giao dịch là một thành phần của phần thưởng khối, trong khi trợ cấp khối giảm một nửa sau mỗi 210,000 khối. (Bitcoin Developer Docs

58. Tổng cầu phí thấp hơn có thể làm suy yếu an ninh ở mức biên. Trong phạm vi BIP 110 làm giảm tổng cầu phí thay vì chỉ phân bổ lại nó, doanh thu thợ đào thấp hơn có thể làm giảm động lực cam kết sức mạnh băm, các yếu tố khác không đổi.

59. Nhu cầu đa dạng có thể làm cho thị trường phí linh hoạt hơn. Thanh toán, kênh, hệ thống lưu ký, ứng dụng tài chính và các sử dụng khác không cần phải đạt đỉnh cùng một lúc.

60. Thông số kỹ thuật không mô hình hóa sự đánh đổi an ninh. Nó lập luận cho các khoản thanh toán rẻ hơn và chi phí nút thấp hơn mà không ước tính các tác động có thể có đối với doanh thu thợ đào, đầu tư băm hoặc độ sâu thị trường phí dài hạn.

VII. Các Công Cụ Thị Trường và Chính Sách Tốt Hơn Tồn Tại

61. Bitcoin đã có một ràng buộc dung lượng trung lập với nội dung. Trọng lượng khối áp đặt một giới hạn chung về dung lượng giao dịch của mỗi khối. (GitHub

62. Phí đã phân phối không gian khối khan hiếm. Người dùng thể hiện sự cấp bách bằng cách đấu giá, và thợ đào chọn các giao dịch hợp lệ theo chính sách riêng của họ.

63. Giới hạn khối và thị trường phí không yêu cầu người dùng khai báo mục đích. Chúng áp dụng tính hợp lệ kỹ thuật và giới hạn tài nguyên thay vì một bài kiểm tra ngữ nghĩa về việc liệu một giao dịch có đủ tính tiền tệ hay không.

64. Chính sách chuyển tiếp vẫn là một công cụ ít cưỡng chế hơn. Các triển khai và người vận hành nút có thể chọn chuyển tiếp các giao dịch chưa được xác nhận nào mà không cần định nghĩa lại các khối hợp lệ. Chính sách sóng mang dữ liệu của Bitcoin Core có thể cấu hình được. (GitHub

65. Chính sách khai thác vẫn là tự nguyện. Thợ đào có thể loại trừ các lớp giao dịch khỏi các mẫu khối của riêng họ mà không buộc mọi nút xác thực phải từ chối các khối chứa chúng.

66. Chính sách là không hoàn hảo, nhưng sự không hoàn hảo không phải là thất bại. Gửi trực tiếp cho thợ đào có thể bỏ qua các bộ lọc chuyển tiếp. Hạn chế đó xứng đáng được phân tích, không phải là một bước nhảy tự động đến lệnh cấm đồng thuận.

67. Không có giao dịch nào có quyền được đưa vào. Một thợ đào có thể từ chối một giao dịch theo chính sách riêng của mình, nhưng làm cho một giao dịch trước đây hợp lệ trở nên không hợp lệ qua một fork là một hành động có hậu quả lớn hơn nhiều.

68. Định giá tài nguyên có thể được cải thiện mà không phân loại mục đích. Nếu một số cấu trúc nhất định áp đặt chi phí không cân xứng, Bitcoin có thể nghiên cứu các giới hạn trung lập với nội dung hoặc định giá gắn liền với việc sử dụng tài nguyên có thể đo lường được.

69. Cắt tỉa và các thiết kế dữ liệu tùy chọn xứng đáng được nghiên cứu tiếp tục. Chúng có thể không giải quyết được mọi mối quan tâm, nhưng chúng giải quyết gánh nặng lưu trữ trực tiếp hơn một quy tắc nhằm một phần để báo hiệu rằng một việc sử dụng là không được hoan nghênh.

70. Bản thân BIP thừa nhận rằng chính sách nói chung là nơi thích hợp để chống lại spam. Không có khả năng đảm bảo lọc hoàn hảo của nó không tự nó chứng minh rằng đồng thuận phải được sử dụng. (GitHub

VIII. Nó Khuyến Khích Sự Đổi Mới và Áp Dụng

71. Nó tạo ra hiệu ứng lạnh lẽo. Các nhà phát triển có thể tránh Bitcoin nếu các cấu trúc hiện đang hợp lệ có thể bị đình chỉ thông qua đồng thuận để đàn áp một việc sử dụng liên quan.

72. Nó ưu đãi các trường hợp sử dụng hiện tại. "Tất cả các trường hợp sử dụng tiền tệ đã biết" bảo vệ hiện tại, không phải tương lai.

73. Nó phá hủy giá trị lựa chọn trước khi giá trị có thể được khám phá. Việc sử dụng tốt nhất trong tương lai của một móc nâng cấp có thể chưa có tên.

74. Nền tảng ổn định rất quan trọng đối với các hợp đồng dài hạn. Ví, hệ thống lưu ký, kênh thanh toán và giao thức tài chính cần sự tự tin rằng các cấu trúc giao dịch hợp lệ sẽ vẫn khả dụng.

75. Nó thu hẹp không gian thiết kế script. Điều đó có thể làm cho một số cấu trúc lớn hơn, đắt hơn, kém thanh lịch hơn hoặc tạm thời không thể thực hiện được.

76. Nó có thể trì hoãn nghiên cứu hợp đồng tiên tiến. BIP chấp nhận rõ ràng rằng công việc kiểu BitVM có thể cần phải chờ đợi hoặc tiến hành trên testnet và sidechain. (GitHub

77. Nó đẩy thử nghiệm ra khỏi Bitcoin bằng đồng thuận. Testnet và sidechain rất hữu ích, nhưng các nhà xây dựng không nên bị dịch chuyển khỏi lớp cơ sở nếu không có một trường hợp an ninh thuyết phục.

78. Các hệ thống Lớp 2 trong tương lai có thể phụ thuộc vào các móc chưa được sử dụng ngày hôm nay. Tính linh hoạt của lớp cơ sở có thể hỗ trợ quy mô mà không yêu cầu hoạt động lớp cơ sở thường xuyên.

79. Các ứng dụng có thể củng cố tiền tệ. Ví tốt hơn, lưu ký, thanh toán, tín dụng, chứng khoán và hệ thống bằng chứng có thể làm tăng tiện ích, tính thanh khoản và nhu cầu của Bitcoin.

80. Bitcoin không cần phải chọn giữa tiền tệ và công nghệ. Sức mạnh tiền tệ của nó có thể được củng cố bởi một mạng lưới mở hỗ trợ các ví, hợp đồng, lưu ký, thanh toán và đổi mới an toàn.

IX. Cơ Chế Kích Hoạt Quá Mạnh

81. Ngưỡng 55 phần trăm là một sự khác biệt lớn so với BIP 9. BIP 9 quy định ngưỡng sẵn sàng của thợ đào là 95 phần trăm; BIP 110 đề xuất 55 phần trăm.

82. Một hạn chế gây tranh cãi nên đòi hỏi sự tự tin lớn hơn, không phải ít hơn. Thời hạn tạm thời không làm cho lỗi phối hợp trở nên vô hại.

83. Tín hiệu thợ đào không phải là một cuộc trưng cầu dân ý về tất cả người dùng Bitcoin. Sức mạnh băm bảo mật và sắp xếp thứ tự các giao dịch, nhưng người nắm giữ, sàn giao dịch, ví, thương nhân, người lưu ký và doanh nghiệp xác định các quy tắc và tài sản nào họ chấp nhận về mặt kinh tế.

84. Tín hiệu bắt buộc thay đổi ý nghĩa của việc không tham gia. Trong cửa sổ được chỉ định, các nút thực thi sẽ từ chối các khối không phát tín hiệu bit 4.

85. Việc triển khai được thiết kế để khóa chặt không muộn hơn một độ cao định trước trên chuỗi thực thi. Điều đó mạnh mẽ hơn là chỉ đơn thuần quan sát sự sẵn sàng tự nguyện.

86. Việc không có trạng thái FAILED loại bỏ một lối thoát sạch sẽ. Một đề xuất không thể thu hút đủ sự hỗ trợ tự nguyện sẽ có thể hết hạn mà không cần phối hợp bắt buộc. (GitHub

87. Cỗ máy kích hoạt không thể sản xuất sự đồng thuận. Nó có thể phối hợp các trạng thái phần mềm, nhưng nó không thể tạo ra sự đồng thuận xã hội và kinh tế.

88. Thực thi khác nhau có thể chia rẽ mạng lưới. Nếu những người tham gia có ý nghĩa kinh tế áp dụng các quy tắc hợp lệ không tương thích, kết quả có thể là một sự chia tách chuỗi hoặc sự không chắc chắn kéo dài.

89. Một sự chia tách tạm thời sẽ không phải là chuyện nhỏ. Tính thanh khoản, lưu ký, thanh toán, kế toán và niềm tin của người dùng đều có thể bị ảnh hưởng.

90. Sự đồng thuận cứng rắn là hệ thống miễn dịch của Bitcoin. Hạ thấp tiêu chuẩn cho một hạn chế trường hợp sử dụng gây tranh cãi có thể tạo ra một rủi ro nghiêm trọng hơn vấn đề lưu trữ dữ liệu mục tiêu.

X. Tiền Lệ Nguy Hiểm Hơn Mục Tiêu

91. Các quy tắc hết hạn, nhưng tiền lệ thì không. Các chiến dịch trong tương lai có thể trích dẫn BIP 110 như bằng chứng rằng đồng thuận có thể được sử dụng để đàn áp hoạt động hợp lệ không được ưa chuộng.

92. Cùng một logic có thể được tái sử dụng. Một phe phái có thể gắn nhãn một việc sử dụng khác là phi tiền tệ, có hại, rủi ro pháp lý hoặc không được hỗ trợ và tìm cách loại trừ nó.

93. "Sử dụng không được hỗ trợ" là một danh mục có thể mở rộng. Bitcoin không có người quản lý sản phẩm trung tâm nào có thể định nghĩa vĩnh viễn phạm vi được chấp thuận của nó.

94. Các ranh giới dựa trên mục đích trở thành các ranh giới chính trị. Một khi tính hợp lệ phụ thuộc vào các phán đoán về việc sử dụng hợp pháp, các cuộc tranh luận về giao thức trở thành các cuộc cạnh tranh về giá trị và quyền lực.

95. Mục tiêu hôm nay không giới hạn mục tiêu ngày mai. Các công cụ bảo mật, lưu ký mới lạ, thanh toán stablecoin, hệ thống token, ứng dụng doanh nghiệp hoặc các sử dụng không được ưa chuộng khác có thể phải đối mặt với các lập luận tương tự. Đây không phải là một dự đoán. Đó là một rủi ro quản trị.

96. Mọi hạn chế đều được trình bày là ngoại lệ. Các tiền lệ được tạo ra chính xác bởi các trường hợp mà những người ủng hộ chúng coi là duy nhất.

97. Sự gắn kết xã hội là một tài sản khan hiếm. Mã hóa một tranh chấp văn hóa thành đồng thuận có thể tiêu thụ lòng tin và năng lực phối hợp cần thiết cho các mối đe dọa nghiêm trọng hơn.

98. Mọi bên liên quan đều xứng đáng được lắng nghe. Các nhà phát triển, người vận hành nút, thợ đào, người nắm giữ, ví, sàn giao dịch, người lưu ký, công ty và tổ chức đều chịu các rủi ro và trách nhiệm khác nhau.

99. Rủi ro về vốn xứng đáng được xem xét mà không cần trao quyền kiểm soát. Những người nắm giữ lớn, thợ đào, sàn giao dịch, tổ chức lưu ký và tập đoàn không sở hữu sự đồng thuận. Các nhà phát triển hay người vận hành nút riêng lẻ cũng không. Một thỏa thuận bền vững đòi hỏi sự phối hợp giữa tất cả họ.

100. Sự tham gia của doanh nghiệp là hợp pháp khi nó củng cố Bitcoin. Các công ty cho phép mọi người tổ chức dưới khuôn khổ pháp luật với quy mô, trách nhiệm giải trình, vốn và tính liên tục. Họ không xứng đáng có thẩm quyền đặc biệt, nhưng cũng không nên bị coi là người ngoài cuộc của một mạng lưới tiền tệ toàn cầu.

XI. Một Con Đường Tốt Hơn Đang Hiện Hữu

101. Những người tham gia có thể phản đối việc lưu trữ dữ liệu mà không cần thay đổi sự đồng thuận. Họ có thể từ chối sử dụng, quảng bá, lập chỉ mục, chuyển tiếp hoặc đào dữ liệu đó.

102. Các lựa chọn phần mềm chặt chẽ hơn có thể vẫn mang tính tự nguyện. Các bản triển khai cạnh tranh và các chính sách có thể cấu hình là những tính năng của một mạng lưới mở, chứ không phải khiếm khuyết.

103. Chúng ta có thể cải thiện việc đo lường trước khi can thiệp. Công bố dữ liệu có thể tái tạo về băng thông, dung lượng lưu trữ, thời gian xác thực, tăng trưởng UTXO, dịch chuyển phí và kinh tế nút.

104. Chúng ta có thể nhắm mục tiêu vào các chi phí tài nguyên có thể đo lường. Một quy tắc hẹp gắn liền với một rủi ro từ chối dịch vụ hoặc xác thực đã được chứng minh sẽ dễ bảo vệ hơn một gói quy tắc rộng một phần gắn với mục đích nhận thức.

105. Chúng ta có thể cải thiện vị trí dữ liệu. Các cam kết tốt hơn, lưu trữ tùy chọn, tỉa bớt dữ liệu và kiến trúc Lớp 2 có thể giảm bớt gánh nặng trong khi vẫn duy trì chức năng.

106. Chúng ta có thể cải thiện tính minh bạch của thị trường phí. Các công cụ và mô hình tốt hơn có thể cho thấy ai trả phí, ai chịu chi phí và việc sử dụng nào thực sự lấn át các khoản thanh toán.

107. Chúng ta có thể bảo tồn các móc nâng cấp trong khi nghiên cứu vẫn tiếp tục. Dung lượng không được sử dụng không nhất thiết là lãng phí khi nó bảo vệ các đường dẫn soft-fork trong tương lai.

108. Chúng ta có thể chờ đợi sự liên kết áp đảo. Chi phí của việc chờ đợi nên được cân nhắc với chi phí của một fork không cần thiết. Trong trường hợp không có bằng chứng thuyết phục về tình trạng khẩn cấp và sự đồng thuận rộng rãi, sự kiềm chế là lựa chọn mặc định an toàn hơn.

109. Chúng ta có thể bất đồng mà không biến đồng minh thành kẻ thù. Những người ủng hộ BIP 110 đang cố gắng bảo vệ Bitcoin. Phản hồi tôn trọng là giải quyết các mối quan tâm của họ trong khi bác bỏ một biện pháp khắc phục tạo ra nhiều rủi ro hơn.

110. Phương thuốc được đề xuất còn nguy hiểm hơn căn bệnh. BIP 110 sẽ sử dụng sự đồng thuận để thu hẹp hoạt động hợp lệ, hạn chế các lựa chọn trong tương lai, làm phức tạp việc triển khai và thiết lập một tiền lệ mà sau này nó không thể xóa bỏ. Điều đó khiến nó trở thành một Đề xuất Gây hại cho Bitcoin.

Những Người Bảo Vệ Tính Trung Lập

Sức mạnh của Bitcoin không phải là ai cũng đồng ý về mọi cách sử dụng. Sức mạnh của nó nằm ở chỗ sự bất đồng được kiềm chế bởi các quy tắc trung lập và sự đồng thuận cứng rắn.

Phí định giá không gian khối. Các nút chọn chính sách và xác thực sự đồng thuận. Thợ đào xây dựng khối. Người nắm giữ phân bổ vốn. Nhà phát triển đề xuất mã. Công ty xây dựng cơ sở hạ tầng và ứng dụng. Các thay đổi giao thức chỉ nên được chấp thuận khi xác thực, bảo mật, tiện ích và vốn đạt được sự liên kết áp đảo.

Đây không phải là sự bảo vệ cho mọi bản khắc, token, tệp tin hay ứng dụng. Đây là sự bảo vệ cho các quy tắc trung lập cho phép Bitcoin duy trì tính mở trong khi thị trường thưởng cho những gì hữu ích và từ bỏ những gì không.

Bitcoin nên duy trì tính bảo thủ ở lớp cơ sở. Đối với tôi, điều đó có nghĩa là bác bỏ BIP 110.

Bitcoin không cần những người bảo vệ sự thuần khiết.

Nó cần những người bảo vệ tính trung lập.

Nguồn Chính

Phân tích này chủ yếu dựa trên BIP 110 phiên bản 1.0.0; các định nghĩa về quy trình và trạng thái của BIP 3; thiết kế kích hoạt của BIP 9; các BIP 141, 341 và 342; tài liệu về chính sách vật mang dữ liệu của Bitcoin Core; tài liệu về tỉa bớt dữ liệu của Bitcoin Core; và tài liệu tham khảo về phần thưởng khối của nhà phát triển Bitcoin. (GitHub

Lưu một chạm

Đọc sâu bài viết viral bằng AI trong YouMind

Lưu nguồn, đặt câu hỏi tập trung, tóm tắt lập luận và biến một bài viết viral thành các ghi chú có thể tái sử dụng trong một không gian làm việc AI duy nhất.

Khám phá YouMind
Dành cho nhà sáng tạo

Biến Markdown của bạn thành bài viết 𝕏 gọn gàng

Khi bạn đăng bài viết dài của riêng mình, việc định dạng hình ảnh, bảng và khối mã cho 𝕏 rất mệt mỏi. YouMind biến cả bản nháp Markdown thành một bài viết 𝕏 gọn gàng, sẵn sàng để đăng.

Thử Markdown sang 𝕏

Thêm pattern để giải mã

Bài viết viral gần đây

Khám phá thêm bài viết viral