Đây là một bài xã luận quan điểm của Shinobi, một nhà giáo dục tự học trong không gian Bitcoin và người dẫn chương trình podcast Bitcoin theo định hướng công nghệ.
Bất ngờ lớn, các Bitcoiners đang tranh cãi dữ dội về một đề xuất bộ thay đổi sẽ được đưa vào bản phát hành tiếp theo của Bitcoin Core. Chọn tham gia thay thế theo phí (RBF) là một tính năng chính sách mempool được đề xuất vào năm 2015 để cung cấp cho người dùng một công cụ để giải quyết các khoản phí tăng đột biến nhanh chóng dẫn đến giao dịch của họ bị kẹt chưa được xác nhận trong mempool trong một khoảng thời gian dài.
Rõ ràng, đây sẽ là một vấn đề đối với bất kỳ việc sử dụng Bitcoin nào nếu khối lượng giao dịch tăng trung bình cao hơn số lượng giao dịch có thể được xử lý trong blockchain, vì vậy trừ khi bạn nghĩ rằng điều đó sẽ không bao giờ xảy ra đây là một chức năng cần thiết trên mạng.
Việc thay thế giao dịch thực sự đã được đưa vào và có thể có trong bản phát hành ban đầu của phần mềm trước khi Satoshi Nakamoto biến mất. Cuối cùng anh ta đã vô hiệu hóa tính năng này vì cách anh ta triển khai nó ban đầu đã tạo ra một vector cho các cuộc tấn công từ chối dịch vụ chống lại các nút. Việc triển khai của anh ấy cho phép thay thế bất kỳ giao dịch nào mà không phải trả phí cao hơn, điều này về cơ bản sẽ cho phép người dùng gửi một giao dịch và sau đó bắt đầu phát một số lượng thay thế không hạn chế lên mạng. Điều này rõ ràng sẽ cho phép gửi thư rác các nút với lượng dữ liệu khổng lồ mà không yêu cầu bằng chứng công việc và nghiêm trọng sẽ làm tăng chi phí chạy một nút.
Trong những năm qua, một số các đề xuất khác nhau để thay thế giao dịch được cải tiến và an toàn hơn chương trình đã được thảo luận. Chúng tôi sẽ nhanh chóng đi qua tất cả những điều này.
RBF đầy đủ
Biến thể đơn giản nhất của RBF. Bất kỳ giao dịch nào cũng có thể bị thay thế miễn là giao dịch thay thế ban đầu phải trả phí cao hơn giao dịch đang thay thế. Bằng cách đó, tất cả các giao dịch đều có thể thay thế được, nhưng yêu cầu trả phí cao hơn mỗi khi bạn thay thế một giao dịch ngăn chặn vô số thư rác các phiên bản mới của các nút quá tải giao dịch.
RBF Nhìn thấy Đầu tiên An toàn
Điều này được đề xuất cho phép thay thế tất cả các giao dịch trong mempool, với một cảnh báo đặc biệt; tất cả các kết quả đầu ra trong giao dịch ban đầu cũng phải được bao gồm trong giao dịch thay thế, bao gồm cả đầu ra thay đổi. Nó vẫn yêu cầu tăng phí để thay thế một giao dịch, nhưng yêu cầu duy trì các đầu ra giống nhau có nghĩa là bạn phải thêm đầu vào mới và đầu ra thay đổi thứ hai, vì không thể thay đổi đầu ra ban đầu. Điều này dẫn đến các giao dịch lớn hơn phải trả nhiều hơn trong tổng số phí để đảm bảo người thay thế đang trả mức phí cao hơn.
RBF bị trì hoãn
Đây là một đề xuất cho phép bất kỳ giao dịch nào được thay thế trong mempool, nhưng chỉ sau khi một số khối nhất định đã trôi qua kể từ khi nút nhìn thấy giao dịch ban đầu. Ý tưởng là điều này sẽ cho phép các giao dịch bị mắc kẹt trong môi trường phí cao được thay thế và xác nhận nhanh hơn, nhưng thời gian chậm trễ trong thời gian sớm có thể được thay thế sẽ ngăn cản các nỗ lực chi tiêu gấp đôi không xác nhận.
Opt-In RBF
Đây là những gì đã được triển khai vào năm 2016 như được định nghĩa trong BIP 125 . Các giao dịch chỉ có thể được thay thế nếu chúng đặt một cờ cụ thể trong giao dịch chọn thay thế hoặc nếu một trong những tổ tiên của chúng đã thực hiện trong trường hợp chuỗi giao dịch chưa được xác nhận, để cho phép những người nhận tiền biết liệu giao dịch chưa được xác nhận có được thực hiện hay không có thể thay thế trong mempool.
Cuộc tranh cãi lớn hiện nay là bản phát hành tiếp theo của Core, 0.24, được thiết lập để giới thiệu cờ chính sách mempool RBF đầy đủ. Điều đó có nghĩa là gì? Nó sẽ cung cấp cho người dùng một tùy chọn có thể định cấu hình để thay đổi chính sách mempool cục bộ của họ từ RBF chọn tham gia thành RBF đầy đủ; theo mặc định, tùy chọn sẽ bị tắt (các nút sẽ sử dụng RBF đầy đủ). Vậy tại sao mọi người lại ủng hộ sự thay đổi này? Các doanh nghiệp chấp nhận giao dịch không xác nhận phụ thuộc vào phần lớn mempools của các nút từ chối thay thế các giao dịch chưa chọn tham gia RBF bằng cờ giao dịch. Họ làm điều này bằng cách kết nối một cách chiến thuật nút của họ với một số lượng lớn các nút khác trên toàn mạng. Điều này cho phép họ phát hiện rất nhanh sự hiện diện của một giao dịch chi tiêu gấp đôi trên mạng, vì nó phải được thực hiện gần như ngay lập tức nếu một giao dịch không được gắn cờ là RBF để có cơ hội tốt đến tay thợ đào. Cũng cần chỉ ra rằng mọi doanh nghiệp trên mạng không thể làm điều này nếu không đồng bộ hóa mạng một cách hiệu quả. Các doanh nghiệp này cho rằng RBF đầy đủ”phá vỡ”mô hình kinh doanh sử dụng RBF của họ. Một số thậm chí đã chỉ trích các nhà phát triển cốt lõi là”ép buộc”một thay đổi ảnh hưởng tiêu cực đến các doanh nghiệp này.
Thực tế đơn giản là chi tiêu gấp đôi luôn luôn có thể thực hiện được, việc chọn tham gia RBF hoặc RBF đầy đủ sẽ không thay đổi điều này. Hơn nữa, chỉ cần tạo một tùy chọn để thay đổi chính sách mempool cục bộ của riêng bạn (được đặt thành tắt theo mặc định) không có cách nào chỉ định thay đổi cho bất kỳ ai, đó là một tùy chọn được cung cấp cho người dùng để tự lựa chọn. Vào cuối ngày khi nói đến giao dịch nào thực sự sẽ được đưa vào khối tiếp theo, mempools duy nhất quan trọng là các thợ đào’. Các mempools của các nút người dùng cá nhân không là gì khác ngoài một chuỗi lưu trữ bộ nhớ với mục đích cuối cùng là tuyên truyền tất cả các giao dịch chưa được xác nhận đó cho các thợ đào để cuối cùng chúng có thể được đưa vào một khối.
Chính sách Mempool được sử dụng như một loại cơ chế an toàn mềm để ngăn chặn các cuộc tấn công từ chối dịch vụ vào các nút và bảo vệ người dùng không bị tự bắn vào chân với các giao dịch và tập lệnh phức tạp. Nhiều loại giao dịch hợp lệ theo sự đồng thuận, được phép bao gồm trong một khối, nhưng sẽ không được chuyển tiếp bởi chính sách mempool mặc định của các nút. Tuy nhiên, điều này không có tác dụng gì để ngăn một người dùng được xác định chuyển tiếp một giao dịch sẽ bị các nút trên mạng bỏ qua trực tiếp đến một người khai thác.
Đó là mấu chốt của vấn đề. Tất cả những gì cần làm là các thợ đào thiết lập một API để gửi trực tiếp các giao dịch cho họ, mà nhiều người đã có và các hạn chế của chính sách mempool trên toàn mạng không quan trọng. Bạn chỉ có thể cung cấp một giao dịch trực tiếp cho các thợ đào và bỏ qua mọi quy tắc về thời điểm có thể thay thế thứ gì đó trong mempool của các nút khác. Hãy nghĩ về những động lực của điều đó-nếu có tiền được tạo ra bằng cách khai thác một loại giao dịch nhất định, nhưng mempools trên toàn mạng sẽ không chuyển tiếp chúng, bạn sẽ làm gì với tư cách là một người khai thác? Chỉ cần chấp nhận chúng trực tiếp. Trợ cấp càng giảm và phí giao dịch càng tăng theo tỷ lệ phần trăm doanh thu của thợ đào, thì càng không thể tránh khỏi việc thợ đào sẽ chỉ trực tiếp chấp nhận các sản phẩm thay thế trả phí cao hơn nếu các nút trên mạng không chuyển tiếp chúng một cách gián tiếp. Không thể tránh được.
Thay đổi này không thay đổi chính sách mempool mặc định cho Bitcoin Core, nó chỉ đưa ra một tùy chọn cho một nhà điều hành nút riêng lẻ để thay đổi chính sách mempool cục bộ của họ nếu họ muốn.
Và tôi có thể nói thêm, đây là lựa chọn luôn có sẵn nếu người dùng chọn sửa đổi ứng dụng khách của họ. Tất cả những gì nó làm là đưa ra một lựa chọn luôn có sẵn cho người dùng đơn giản hơn. Các ưu đãi chắc chắn dẫn đến trạng thái mà tất cả các giao dịch sẽ bị thay thế nếu các thợ đào hành động theo cách hợp lý về mặt kinh tế-điều đó là không thể tránh khỏi. Câu hỏi duy nhất của vấn đề là, phần mềm có nên phản ánh những khuyến khích đó hay không, theo cách cho phép người dùng cá nhân tự quyết định chính sách nào sẽ sử dụng cho mempool của họ, hay mọi người chỉ nên ngồi một chỗ và để việc truyền bá các giao dịch tập trung vào việc gửi trực tiếp cho các thợ đào chúng tôi?
Kết quả cuối cùng là như nhau, nhưng việc chờ đợi các thợ đào thu hút để gửi giao dịch trực tiếp sẽ gây ra những hậu quả rất tiêu cực. Nó sẽ có những tác động về quyền riêng tư đối với những người truyền phát các giao dịch lên mạng và nó có thể gây ra những hậu quả rất tiêu cực đối với khả năng của người dùng trong việc quyết định loại phí phải trả cho một giao dịch. Nếu phần lớn các giao dịch đang chờ xử lý không còn được phát công khai trên mạng, thì người dùng sẽ có cái nhìn không đầy đủ về những người họ đang đấu thầu để đưa vào một khối. Những người khai thác thậm chí có thể nói dối về việc phân phối phí để khuyến khích người dùng trả nhiều hơn những gì họ phải trả.
Nhược điểm thực sự duy nhất của việc cung cấp tùy chọn này là RBF đầy đủ có thể không hoạt động nhất quán nếu chỉ một lượng nhỏ mạng, bao gồm cả những người khai thác, chọn bật RBF đầy đủ. Tuy nhiên, về cơ bản điều này không có gì khác biệt so với việc nâng cấp lên SegWit. Trong giai đoạn chuyển tiếp đó, các nút không được nâng cấp sẽ không chuyển tiếp các giao dịch SegWit vì chúng không có khả năng xác thực chúng, vì vậy trong khoảng thời gian đó, động thái lan truyền giống nhau không nhất quán cho đến khi đủ người dùng nâng cấp. Nhưng cuối cùng, điều đó không thay đổi thực tế rằng việc nâng cấp là quyết định của người dùng cá nhân.
Cuối cùng, việc chống lại RBF đầy đủ chỉ là phủ nhận thực tế của các ưu đãi trên mạng. Không có gì được ra lệnh cho bất cứ ai, một tùy chọn cấu hình chỉ đơn giản là cung cấp cho người dùng cá nhân một sự lựa chọn để thực hiện cho chính họ. Tôi thấy thật kỳ lạ khi đồng thời, rất nhiều người đều bỏ qua thực tế của các biện pháp khuyến khích để tranh luận rằng một phương tiện nhận thanh toán không an toàn có thể được giữ an toàn bất chấp các ưu đãi, cũng như mọi người đang tranh luận rằng người dùng phần mềm không được phép lựa chọn cách thức để cấu hình phần mềm của riêng họ.
Nút của tôi, quy tắc của tôi, phải không?
Đây là một bài đăng của Shinobi. Các ý kiến được bày tỏ hoàn toàn là của riêng họ và không nhất thiết phản ánh ý kiến của BTC Inc hoặc Tạp chí Bitcoin.
