Breaking News
Home / Tin tức / Bảo vệ túi: Cắt giảm một nửa giao dịch để giải quyết tắc nghẽn mạng Bitcoin

Bảo vệ túi: Cắt giảm một nửa giao dịch để giải quyết tắc nghẽn mạng Bitcoin

Sự tắc nghẽn mạng Bitcoin có thể thay đổi dữ dội. Trong vài giờ của một số ngày, hàng chục ngàn giao dịch đang chờ để được bao gồm trong một khối, khiến phí tăng đột biến và khiến nhiều người dùng chờ đợi. Trong những giờ chậm hơn, trong khi đó, có rất nhiều giao dịch đủ để lấp đầy tất cả các khối và mức phí nhỏ nhất đủ để xác nhận nhanh.

Sự tắc nghẽn mạng trong giờ cao điểm tất nhiên là một vấn đề lớn đối với các dịch vụ cần thực hiện nhiều giao dịch, nhanh chóng. Ví dụ, trao đổi, nhóm khai thác hoặc dịch vụ trả lương, đôi khi trả hàng trăm người dùng đồng thời – và những người dùng này có thể thiếu kiên nhẫn để lấy tiền của họ. Do đó, các dịch vụ phải trả phí cao, trả lại tất cả các giao dịch khác trên mạng Bitcoin trở lại hàng đợi.

Bây giờ, người đóng góp Bitcoin Core Jeremy Rubin tin rằng ông đã tìm ra cách giải quyết vấn đề tắc nghẽn mạng một cách đáng tin cậy, tăng thông lượng Bitcoin trên các giờ cao điểm.

Đề xuất của ông được gọi là OP_SECURETHEBAG.

Bảo vệ túi

Để hiểu OP_SECURETHEBAG (mà từ giờ trở đi, chúng tôi chỉ đơn giản gọi cho Secure Secure Bag Bag), hãy để lấy một ví dụ thực tế và bắt đầu từ những điều cơ bản. Trong ví dụ này, tất cả 12 khách hàng đều yêu cầu trao đổi rút tiền trong khi phí cao. (Trong thực tế, điều này có thể dễ dàng là 1.200 khách hàng – nhưng với 12, khái niệm này dễ giải thích hơn.)

Ngay cả khi không có Túi an toàn, việc trao đổi là hợp lý và không tạo ra 12 giao dịch riêng biệt để thanh toán riêng cho từng khách hàng. Thay vào đó, để tiết kiệm chi phí, nó tạo ra một giao dịch được bó theo nhóm, nhỏ gọn hơn. Giao dịch bao gồm, ví dụ, ba đầu vào (đề cập đến các địa chỉ từ các địa chỉ trực tuyến, tất cả ba đầu vào thuộc về trao đổi) và 12 đầu ra (bao gồm các địa chỉ đầu mối đến các khách hàng khác nhau). Trong ví dụ này, số tiền cộng lại độc đáo, do đó không có địa chỉ thay đổi.

Trong các hình ảnh bên dưới, giao dịch sẽ trông giống như giao dịch A ở bên phải – không giống như 12 giao dịch riêng lẻ như được hiển thị bên trái.

Hình ảnh được chụp từ bài thuyết trình của Jeremy Rubin [trênOP_SECURETHEBAGkhimởrộngBitcoin2019

Bởi vì giao dịch theo đợt bao gồm rất nhiều đầu ra – một cho mỗi khách hàng – nó khá lớn, dữ liệu khôn ngoan. Một giao dịch càng lớn thì càng có nhiều chi phí để đưa nó vào một khối. Và trong giờ cao điểm, việc trao đổi sẽ được xác nhận giao dịch một cách nhanh chóng. (Không đắt bằng 12 giao dịch riêng lẻ, nhưng vẫn đắt.)

Bây giờ, trao đổi có thể bao gồm một mức phí thấp hơn thay vào đó, trong trường hợp đó sẽ chỉ mất một lúc để giao dịch xác nhận. Nhưng cho đến khi nó xác nhận, khách hàng sẽ đợi tiền của họ, không chắc họ có thực sự nhận được hay không: Tiền có thể được chi tiêu gấp đôi cho đến khi giao dịch được bao gồm trong một khối. Điều này khiến khách hàng không hài lòng, và trao đổi không muốn điều đó. (Trong một số trường hợp, nó thậm chí có thể không phải là một lựa chọn để cho khách hàng chờ đợi: ví dụ, dịch vụ trả lương có thể có nghĩa vụ theo hợp đồng để xác nhận giao dịch vào một ngày cụ thể.)

Đây là nơi Secure Bag Bag xuất hiện.

Bảo mật túi là một đề xuất OpCode trực tiếp được đề xuất: một bổ sung cho ngôn ngữ lập trình Bitcoin. OpCode này về cơ bản sẽ cho phép trao đổi, chia tách giao dịch theo đợt của mình thành hai giao dịch: một giao dịch gửi và nhận được giao dịch trực tuyến.

Đầu tiên trong số này – giao dịch gửi tin nhắn – bao gồm ba đầu vào ban đầu, đề cập đến các địa chỉ do sở giao dịch sở hữu. Nhưng nó chỉ bao gồm một đầu ra đặc biệt. Đầu ra này được gọi là đầu ra cam kết và có chứa hàm băm mật mã đặc biệt: một chuỗi số có vẻ ngẫu nhiên nhưng tương đối ngắn.

Hàm băm này về cơ bản đóng vai trò là một số sê-ri duy nhất, liên kết nó với một trong hai giao dịch: giao dịch nhận Nhận. Chìa khóa để bảo mật túi, cách duy nhất mà đầu ra được cam kết có thể được chi tiêu là thông qua giao dịch nhận tiền cụ thể này, mà nó được liên kết thông qua hàm băm. (Về mặt kỹ thuật, hàm băm cam kết với toàn bộ giao dịch nhận được của Keith, ngoại trừ các ưu tiên của Cameron, nhưng đây là một chi tiết triển khai.)

Sau đó, giao dịch nhận tiền điện tử có thể được coi là nửa sau của giao dịch gốc. Nó chỉ chứa một đầu vào, đề cập đến đầu ra đã cam kết từ giao dịch Gửi gửi trên mạng và tất cả 12 đầu ra. Do đó, giao dịch nhận tín hiệu này, với tất cả các kết quả đầu ra, do đó lớn hơn nhiều so với giao dịch gửi trên mạng.

Trong các hình ảnh bên dưới, bạn có thể thấy giao dịch theo đợt thông thường ở bên trái và hai giao dịch được tách riêng (Gửi gửi và nhận nhận) của một khoản thanh toán Túi an toàn ở bên phải.

Hình ảnh được chụp từ bài thuyết trình của Jeremy Rubin trên OP_SECURETHEBAG tại Thu nhỏ Bitcoin 2019

Khi phát hành giao dịch rút tiền cho 12 khách hàng của mình, sàn giao dịch phát sóng cả giao dịch và gửi các giao dịch trực tuyến. Nhưng có một sự khác biệt lớn giữa hai người, và đây là trung tâm của mánh khóe. Giao dịch gửi tin nhắn trên mạng nhỏ hơn bao gồm một khoản phí tương đối lớn, để đảm bảo rằng nó xác nhận nhanh. Vì giao dịch này là nhỏ, dữ liệu khôn ngoan, thậm chí một khoản phí tương đối lớn có thể quản lý được. Ngược lại, giao dịch nhận tiền lớn hơn, bao gồm một khoản phí thấp hơn nhiều, có nghĩa là phải mất một thời gian để trao đổi xác nhận nó.

Ngược lại, giao dịch nhận tiền điện tử lớn hơn, bao gồm một khoản phí thấp hơn nhiều, có nghĩa là phải mất một thời gian để xác nhận. Nhưng lần này, việc chờ đợi một giao dịch phí thấp để xác nhận nên không phải là một vấn đề lớn đối với khách hàng, bởi vì một khi giao dịch gửi tin nhắn đã xác nhận, nó đảm bảo rằng tất cả tiền được đảm bảo cho giao dịch nhận được. Các khoản tiền được neo trong blockchain và không còn nơi nào khác ngoài các khách hàng trao đổi.

Tiền vẫn chưa có, nhưng chiếc túi vẫn được bảo đảm.

Trẻ em trả tiền cho cha mẹ

Mặc dù ví dụ cơ bản như đã nêu ở trên sẽ đảm bảo * rằng các khách hàng trao đổi trên 12 cuối cùng cũng nhận được tiền của họ, nhưng điều này có thể chưa thỏa mãn tất cả trong số họ.

(* Trong trường hợp phí giao dịch không bao giờ giảm xuống mức yêu cầu, giao dịch nhận nhận của ED thực sự sẽ không tự xác nhận; điều này được giải quyết mặc dù cùng một mẹo, như được giải thích trong phần còn lại của bài viết này.)

Ví dụ, Alice, một trong 12 khách hàng, phải trả tiền cho chủ nhà hôm nay. Do đó, chỉ cần biết rằng cô ấy sẽ nhận được tiền của mình cuối cùng cũng không đủ điều kiện – cho dù cô ấy có thực sự nhận được nó hay không. Cô ấy thực sự cần phải có khả năng chi tiêu đầu ra của mình.

Đây là kỹ thuật có thể. Alice có thể lấy đầu ra chưa được xác nhận của mình (một trong số 12) và chi tiêu ngay trong giao dịch mới. Vấn đề duy nhất: Giao dịch Alice của người dùng sẽ chỉ xác nhận sau khi giao dịch nhận được trên mạng cũng được xác nhận. Trong khi đó, chủ nhà của cô đang yêu cầu một giao dịch được xác nhận ngày hôm nay.

May mắn thay, Alice có thể tận dụng một thủ thuật Bitcoin cũ hơn để đảm bảo rằng cả giao dịch nhận được và một giao dịch riêng của cô ấy đều xác nhận: trẻ em trả tiền cho phụ huynh (CPFP). Về cơ bản, nếu Alice bao gồm một khoản phí đủ cao trong giao dịch của mình với chủ nhà, những người khai thác sẽ được khuyến khích bao gồm cả giao dịch nhận Nhận trên một khối – ngay cả khi họ không quan tâm đến phí trên chính giao dịch nhận tiền . Rốt cuộc, họ chỉ nhận được phí Alice Alice bằng cách xác nhận cả hai.

Điều đó nói rằng, việc bù đắp cho giao dịch nhận tiền lớn của người dùng sẽ khá tốn kém. Đó là lý do tại sao trao đổi sử dụng Bảo mật Túi ở nơi đầu tiên. Thay vì trao đổi, giờ đây Alice sẽ thanh toán cho giao dịch theo đợt cho tất cả 12 khách hàng. Điều này sẽ làm cho cô ấy trở thành một khách hàng rất hạnh phúc.

May mắn thay, Secure the Bag cung cấp một giải pháp tốt hơn.

Thanh toán cây

Để giải quyết vấn đề Alice Alice, việc trao đổi có thể đưa thủ thuật Secure the Bag tiến thêm một bước nữa.

Trong ví dụ cơ bản được hiển thị ở trên, giao dịch Gửi tin nhắn của người dùng bao gồm một giao dịch Bảo đảm đầu ra Túi, trong khi một giao dịch nhận được một lượt tiếp nhận bao gồm một đầu vào Bảo mật túi tương ứng và 12 đầu ra bình thường. Nhưng có thể chia nhỏ hơn 12 kết quả đầu ra này qua nhiều giao dịch nhận được nhiều hơn nữa.

Ví dụ, giao dịch gửi tin nhắn trên mạng có thể bao gồm hai giao dịch đầu ra của Secure the Bag, đề cập đến hai giao dịch nhận nhận khác nhau, mỗi giao dịch bao gồm sáu đầu ra bình thường. Tất nhiên, điều này có nghĩa là giao dịch gửi tin nhắn của Keith đắt hơn một chút để được xác nhận nhanh chóng, nhưng chi phí của Alice lề sẽ giảm hơn một nửa: Cô ấy hiện chỉ trả cho năm khách hàng khác thay vì mười một.

Thậm chí tốt hơn, việc trao đổi có thể tạo ra các giao dịch trung gian trực tuyến giữa các giao dịch ban đầu và gửi giao dịch trực tuyến và nhận được các giao dịch cuối cùng! Tất cả các giao dịch trung gian của các thành viên này đều bao gồm một đầu vào Bảo mật đầu vào Túi và một hoặc một số đầu ra Bảo mật đầu ra Túi và có thể là đầu ra bình thường, tạo ra cấu trúc cây. Bằng cách này, việc trao đổi có thể giảm thiểu chi phí CPFP một cách hợp lý, ngay cả đối với những khách hàng cần chi tiêu tiền ngay lập tức. Khách hàng vội vàng sẽ cần phải trả tiền cho các giao dịch trung gian có liên quan đến họ, nhiều nhất và bỏ qua phần còn lại.

Như được hiển thị trong các hình ảnh bên dưới, việc trao đổi có thể tạo ra một cây như vậy một cách sáng tạo như mong muốn, tùy thuộc vào những gì hoạt động tốt nhất cho khách hàng của mình. (Các bước trung gian hơn thường sẽ yêu cầu tổng số dữ liệu giao dịch được xác nhận nhiều hơn trên blockchain – nhưng chi phí ít hơn cho mỗi người dùng. Thanh toán của Chained tương tự như thanh toán trên Cây, nhưng phụ thuộc nhiều hơn vào niên đại của giao dịch.)

Hình ảnh được chụp từ bài thuyết trình của Jeremy Rubin trên OP_SECURETHEBAG tại Thu nhỏ Bitcoin 2019

Chi tiết và triển khai

Bài viết này mô tả các triển khai khá cơ bản của Bảo mật Túi. Trong thực tế, đề xuất có thể được thực hiện và sử dụng theo nhiều cách khác nhau. Ví dụ, thay vì Alice cần sử dụng CPFP để có thể trả tiền cho chủ nhà, cô ấy có thể nhận tiền vào các kênh Lightning và ngay lập tức có thể trả tiền cho chủ nhà của mình thông qua những người đó. Ngoài ra còn có các giải pháp khác, phức tạp hơn để tăng tốc độ giao dịch nhận được trên mạng.

Ngoài ra, bảo mật OpCode được đề xuất, nói đúng ra, không phải là cách duy nhất để hiện thực hóa giải pháp thanh toán hai pha. Ngay cả với giao thức Bitcoin hiện tại, có thể đạt được điều tương tự – nhưng nó sẽ yêu cầu tất cả người nhận phối hợp và hợp tác, điều này không có khả năng trong ví dụ về trao đổi và khách hàng của nó, và kịch bản như vậy sẽ trở nên khó khăn hơn khi nhiều người dùng tham gia . Các giải pháp khác (như giao ước) sẽ yêu cầu nâng cấp giao thức Bitcoin.

Bảo mật Túi cũng sẽ yêu cầu nâng cấp giao thức bằng nĩa mềm tương thích ngược. Rubin đã thực hiện hầu hết các công việc mã hóa cần thiết – mặc dù cả mã và ý tưởng vẫn có thể được xem xét. Hơn nữa, ngay cả khi đề xuất vượt qua tất cả các đánh giá ngang hàng, việc nâng cấp giao thức có thể mất một thời gian để được thông qua. Do đó, hiện tại không có ước tính nào về việc khi nào Secure Bag Bag sẽ tồn tại trên Bitcoin – nếu có.

Cảm ơn Jeremy Rubin về thông tin và phản hồi. Để biết thêm thông tin, dữ liệu mô phỏng và các trường hợp sử dụng khác cho Bảo mật Túi, cũng xem thảo luận Đề xuất cải tiến Bitcoin danh sách gửi thư phát triển ] về chủ đề và bài thuyết trình đầy đủ của Rubin tại Thu nhỏ Bitcoin 2019 ở Tel Aviv:

Bài đăng Bảo mật túi: Cắt giảm một nửa giao dịch để giải quyết tắc nghẽn mạng Bitcoin xuất hiện đầu tiên trên Tạp chí Bitcoin.

About TapchiHyip

Trả lời

Thư điện tử của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *