Cointime

Download App
iOS & Android

“Kênh Lightning để bơm vốn hai chiều” là gì?

Validated Media

Giải thích đơn giản về việc ghép kênh

Về cốt lõi, "nối" là một khái niệm đơn giản: khả năng thay đổi kích thước các kênh sét. Nhưng thời gian trôi qua, ngày càng rõ ràng rằng khả năng thay đổi kích thước các kênh Lightning này sẽ mang lại cho chúng ta nhiều lợi ích bổ sung mà chúng ta thường không ngờ tới và về cơ bản sẽ cải thiện hiệu suất của Lightning Network.

Việc ghép kênh mang lại những cải tiến ở hai khía cạnh:

  • Cải tiến hướng đến người dùng
  • Tính thanh khoản phụ trợ được cải thiện

Cải tiến hướng đến người dùng

Khía cạnh đầu tiên tương đối dễ giải thích: có rất nhiều ứng dụng ví Bitcoin hiện có – điều này chắc chắn là tốt. Nhưng khi các nhà phát triển này phát triển ứng dụng của riêng mình, họ sẽ gặp phải một vấn đề: Ứng dụng này nên được tạo thành ví Bitcoin hay ví Lightning?

Hầu hết các ví sẽ chọn cái này hoặc cái kia, nhưng một số ví tham vọng hơn sẽ chọn làm cả hai! Từ góc độ cơ bản hơn, tất nhiên làm cả hai là giải pháp tốt nhất.

Nhưng điều này mang lại một vấn đề. Những ví này sẽ có “hai bộ số dư” – một bộ là số dư Bitcoin (“trên chuỗi”) và một bộ là số dư Bitcoin trong kênh Lightning. Tôi không biết liệu bạn đã từng hướng dẫn ai đó mới làm quen với Bitcoin chưa, nhưng tôi có thể nói với bạn: việc có hai bộ số dư có thể gây nhầm lẫn cho người dùng mới. Đối với những người chơi Bitcoin có kinh nghiệm, đây không phải là vấn đề, nhưng chúng tôi muốn mọi người đều có thể sử dụng Bitcoin.

Vấn đề "hai bộ số dư" này không phải là vấn đề về thiết kế và vì hai mô hình (quỹ trên chuỗi so với kênh Lightning) về cơ bản là khác nhau nên chúng không thể biến thành "một bộ", nếu không nó sẽ tạo ra các vấn đề mới cho người dùng : Cập nhật Trì hoãn thanh toán kéo dài và/hoặc phí quá cao.

Và việc ghép kênh, nếu có thể được triển khai trong mạng, sẽ trở thành vũ khí bí mật, biến chiếc ví "bộ số dư" thành hiện thực. Bởi vì việc ghép kênh cho phép hai cân này có thể tương tác (chuyển đổi lẫn nhau) với chi phí thấp.

Tính thanh khoản phía sau được cải thiện

Khía cạnh thứ hai, sự gia tăng tính thanh khoản ở phần phụ trợ, có thể khó hiểu hơn, nhưng nó sẽ có tác động đáng kể hơn đến Lightning Network (so với ứng dụng “bộ số dư”).

Lightning Network chạy trên nhiều ngân hàng "vi mô" nằm rải rác trên mạng. Các ngân hàng này chỉ cung cấp một dịch vụ: chuyển tiền theo một hướng nhất định.

Ngân hàng truyền thống yêu cầu một ngân hàng “trung tâm” khổng lồ phê duyệt một số ít ngân hàng “thực” vào một mạng lưới đáng tin cậy. Nhưng Lightning Network thì ngược lại: tại sao chúng ta không để mọi người mở ngân hàng của riêng mình? Liệu nhiều ngân hàng nhỏ có thể giao tiếp với nhau có thể trở thành “ngân hàng phi tập trung”? Nếu có đủ người làm việc này, cuối cùng chúng ta có thể tạo ra thứ gì đó đáng tin cậy như ngân hàng trung ương - hoặc thậm chí đáng tin cậy hơn!

Điều này thực sự đã xảy ra. Số lượng “ngân hàng vi mô” trong Lightning Network không ngừng tăng lên và chúng ta sẽ sớm có 100.000 ngân hàng vi mô — nhiều hơn nhiều so với con số 5.000 ở Hoa Kỳ.

Các ngân hàng vi mô này sẽ cạnh tranh với nhau để định tuyến các giao dịch của bạn và do đó cung cấp dịch vụ rẻ nhất. Để ngân hàng như vậy định tuyến thanh toán, ngân hàng đó phải có sẵn một số tiền được lưu trữ trong một trong các "Tài khoản Lightning" của Bitcoin.

Các ngân hàng vi mô này sẽ cạnh tranh với nhau để định tuyến các giao dịch của bạn và do đó cung cấp dịch vụ rẻ nhất. Để ngân hàng như vậy định tuyến thanh toán, ngân hàng đó phải có sẵn một số tiền được lưu trữ trong một trong các "Tài khoản Lightning" của Bitcoin.

Hãy để tôi cung cấp cho bạn một số số liệu cụ thể: Một ngân hàng Lightning thành công thường duy trì 100 tài khoản Lightning; TA cần liên tục chuyển tiền giữa các tài khoản này và dự đoán hướng người dùng tiếp theo cần thực hiện thanh toán. Nếu họ tình cờ đang trên đường đến "Cửa hàng bánh sandwich của Sally" với số dư tài khoản là 100.000 satoshi thì khi bạn muốn mua bánh sandwich từ Sally, bạn có thể chọn họ để định tuyến thanh toán của mình.

Bây giờ, hãy tưởng tượng một trong những ngân hàng vi mô này quản lý 100 tài khoản, liên tục chuyển tiền giữa các tài khoản để đoán hành vi của người tiêu dùng. Điều này khá khó khăn! Bởi vì sự thật là hành vi của con người rất khó đoán và có rất nhiều đối thủ cạnh tranh cũng muốn làm điều tương tự như bạn.

Vì vậy, việc ghép kênh có liên quan gì đến điều này? Chà, việc chuyển tiền giữa các tài khoản này rất tốn kém - trên thực tế, những ngân hàng chớp nhoáng này yêu cầu đóng và mở tài khoản liên tục. Họ cũng cần giữ một quỹ như một khoản “dự trữ” để có thể triển khai vào Lightning Network nếu có nhu cầu bất ngờ phát sinh.

Việc ghép kênh giúp loại bỏ cả nhu cầu đóng và mở tài khoản tốn kém cũng như nhu cầu duy trì số tiền “dự trữ” nhàn rỗi. Điều này sẽ làm giảm đáng kể chi phí hoạt động, độ phức tạp và những thách thức về vốn nhàn rỗi của các ngân hàng vi mô này. Ghép kênh thực hiện tất cả điều này bằng cách cho phép chuyển tiền trực tiếp giữa các “Tài khoản Lightning” (đồng thời tiết kiệm chi phí nhất có thể). Thậm chí tốt hơn nữa, việc ghép kênh còn làm cho toàn bộ mạng lưới mạnh mẽ hơn bằng cách cho phép các ngân hàng vi mô này duy trì sự độc lập — không còn phụ thuộc vào cái gọi là “nhà cung cấp thanh khoản tập trung”.

Điều này rất thú vị đối với những người đang chạy Lightning Network microbank và tất nhiên điều này cũng tương tự đối với những người dùng Lightning Network như bạn. Nếu các ngân hàng vi mô này có thể hoạt động hiệu quả hơn, khoản tiết kiệm chi phí đương nhiên sẽ được chuyển sang người dùng dưới dạng phí rẻ hơn và thanh toán đáng tin cậy hơn.

Tổng quan về công nghệ nối kênh

Ghép kênh đề cập đến việc chuyển tiền trong kênh Lightning (UTXO tài trợ của kênh) sang UTXO "được ghép" mới. Thao tác cụ thể rất đơn giản - ký một giao dịch 2 trong 2 chữ ký để chuyển tiền đến địa điểm mới. Tuy nhiên, không đơn giản để giữ cho quá trình này không có sự tin cậy.

Trước khi thực sự di chuyển UTXO được tài trợ ban đầu và bất kỳ giao dịch HTLC con nào, giao dịch cam kết phải được xây dựng lại cho UTXO "được ghép" mới.

Tuy nhiên, trước khi tạo lại trạng thái lời hứa đã sao chép cho kênh mới, chúng tôi cần đảm bảo rằng trạng thái trong kênh hiện tại sẽ không bị thay đổi nhanh chóng. Vì vậy, chúng tôi đã giới thiệu một trạng thái sét mới có tên là "SomeThing Fundamental is Underway", viết tắt là "STFU".

STFU sẽ cấm thay đổi trạng thái cam kết của kênh hiện tại trong một khoảng thời gian.

Sau đó, hai nút tham gia vào kênh bắt đầu đàm phán giao dịch bằng giao thức tương tác-tx: mỗi bên có thể thêm cả đầu vào và đầu ra khi đến lượt mình. UTXO cấp vốn của kênh hiện tại sẽ được thêm làm đầu vào cho giao dịch đã thương lượng.

Cả hai bên đều có thể tự do bổ sung thêm đầu vào và đầu ra cho các hoạt động không liên quan, chẳng hạn như mở một kênh khác hoặc thậm chí xử lý việc ghép kênh khác. Tất cả các hoạt động này được kết hợp thành một giao dịch.

Sau khi hoàn tất đàm phán và xây dựng giao dịch, cả hai bên sẽ xác minh giao dịch cuối cùng, xác nhận rằng số dư của giao dịch phù hợp với mong đợi và trả một khoản phí hợp lý cho người khai thác. Sau đó, họ ký giao dịch và đưa chữ ký của mình cho bên kia.

Sau khi hoàn tất đàm phán và xây dựng giao dịch, cả hai bên sẽ xác minh giao dịch cuối cùng, xác nhận rằng số dư của giao dịch phù hợp với mong đợi và trả một khoản phí hợp lý cho người khai thác. Sau đó, họ ký giao dịch và đưa chữ ký của mình cho bên kia.

Sau khi giao dịch được phát sóng, cả hai bên chờ giao dịch nhận được 6 xác nhận khối và khi đó việc ghép nối được coi là "hoàn thành". Lúc này, họ có thể xóa trạng thái của kênh gốc và chỉ quan tâm đến trạng thái của kênh được ghép. Điều này có thể tiết kiệm rất nhiều không gian cơ sở dữ liệu.

(Lưu ý của người dịch: Mô tả ở đây quá thô. Giả sử kênh UTXO hiện có của cả hai bên là UTXO A; và kênh ghép UTXO mà họ muốn tạo thành là UTXO B. Đầu tiên, cả hai bên phải xây dựng kênh UTXO cho UTXO B. Giao dịch đã cam kết được sử dụng làm trạng thái đầu tiên trong kênh mới, đây cũng là một sự đảm bảo không cần tin cậy, sau đó cả hai bên ký để tạo giao dịch UTXO B và phát sóng giao dịch đó. kênh tiếp tục chạy và mỗi bên Nếu bạn cập nhật trạng thái trong kênh gốc, bạn cũng phải cập nhật trạng thái trong kênh mới. Khi UTXO B nhận đủ xác nhận khối, bạn không thể cập nhật trạng thái của kênh gốc nữa, hoặc xóa dữ liệu liên quan đến kênh gốc. Điều này cho phép thay đổi kích thước kênh mà không ảnh hưởng đến hoạt động bình thường của kênh.)

Cách triển khai ghép kênh

Có nhiều bước để triển khai Lightning từ không hỗ trợ nối đến hỗ trợ nối.

Trước tiên, bạn phải quyết định xem trạng thái kênh của mình có cho phép ghi đè chi tiết nguồn vốn hay trạng thái kênh được ghép nối sẽ được coi là trạng thái hoàn toàn mới. Cả hai cách tiếp cận đều có thể hoạt động và cách nào lý tưởng hơn tùy thuộc vào cách triển khai của bạn xây dựng trạng thái kênh.

Lợi ích của hai bộ trạng thái kênh được nhân rộng:

  • Trạng thái kênh (về cơ bản) bỏ qua việc ghép nối

Nhược điểm của hai bộ trạng thái kênh được sao chép:

  • Mã cam kết của bạn phải được sao chép ở cả hai nhóm trạng thái, điều này phá vỡ tính chất "hộp đen" của kênh trong việc quản lý trạng thái của nó.

Ưu điểm của việc chỉ có một trạng thái kênh:

  • Cấu trúc của Promise vẫn giữ nguyên, chỉ có trạng thái Promise cần điều chỉnh một chút
  • Trạng thái kênh gần với những gì đang diễn ra về cơ bản

Nhược điểm của việc chỉ có một trạng thái kênh:

  • Tất cả các mã đặt trước hoặc lưu vào bộ nhớ đệm chi tiết cấp vốn và thông tin số dư của kênh phải "hiểu" việc ghép kênh

Bất kể áp dụng phương pháp nào, công việc bổ sung đều được yêu cầu để quản lý ID kênh và ID kênh ngắn, đặc biệt khi sử dụng chúng làm khóa, cần được xử lý trên toàn bộ cơ sở mã.

Đối với một cơ sở mã nhất định, bạn nên xem xét ưu điểm và nhược điểm của từng phương pháp—cả khó khăn trong việc tái cấu trúc và nguy cơ phát sinh lỗi.

Tiếp theo, bạn sẽ cần một khối xây dựng giao dịch tương tác có thể tái sử dụng. Mô-đun này xử lý tất cả các thông báo loại TX_ADD_INPUT/TX_ADD_OUTPUT. Bạn cũng cần mô-đun này để hỗ trợ tài trợ kép, đó là lý do tại sao nhiều triển khai phát triển các mô-đun như vậy để tài trợ kép.

Mô-đun này cũng sẽ hữu ích trong tương lai "nối để đóng" và có thể cả các bổ sung thông số kỹ thuật Lightning Network khác.

Giao thức giao dịch tương tác rất giống với biến thể tài trợ hai chiều, nhưng có một số khác biệt. Vui lòng ghi nhớ những khác biệt này khi phát triển để mô-đun như vậy có thể chạy trong các tình huống khác nhau.

Bước tự nhiên tiếp theo là triển khai logic "STFU". Nhiều người nhận thấy giao thức STFU phức tạp hơn tưởng tượng. Điều này là do thông báo STFU thực sự là một yêu cầu cho chế độ STFU. Nó sẽ không kích hoạt trừ khi nhận được "STFU".

Bước tự nhiên tiếp theo là triển khai logic "STFU". Nhiều người nhận thấy giao thức STFU phức tạp hơn tưởng tượng. Điều này là do thông báo STFU thực sự là một yêu cầu cho chế độ STFU. Nó sẽ không kích hoạt trừ khi nhận được "STFU".

Nếu bên kia bận làm việc khác, chẳng hạn như thêm HTLC và cập nhật giao dịch đã cam kết, họ sẽ không trả lời STFU cho đến khi hoàn thành thao tác.

Theo văn bản này, chỉ ghép kênh mới sử dụng chế độ STFU, nhưng điều này có thể sẽ thay đổi trong tương lai. Do đó, khi phát triển mô-đun STFU, bạn nên nghĩ đến việc sử dụng nó trong tương lai.

Có một số cân nhắc đặc biệt liên quan đến chế độ STFU. Rất hiếm trường hợp cả hai bên muốn khởi tạo việc ghép kênh cùng một lúc. Hãy nhớ xử lý những tình huống thắt nút này một cách chính xác nhé.

Nói chung, khi khởi tạo, bạn cần xử lý PSBT (Giao dịch Bitcoin được ký một phần) bao gồm đầu vào và đầu ra. Người dùng của bạn có thể muốn thêm đầu vào và đầu ra cho giao dịch này cũng như số lượng thay đổi kích thước kênh tương đối. Bạn sẽ cần gửi các thay đổi về số lượng tương đối để gửi mối nối cũng như splice_ack. Hãy nhớ rằng, cả hai bên đều có thể cung cấp số lượng biến thể, vì vậy hãy đảm bảo phát triển một phần bổ trợ cho bên nhận để cảnh báo họ về các biến thể PSBT.

Các bình luận

Tất cả bình luận

Recommended for you