BTC

$96,000

5.73%

ETH

$3,521.91

3.97%

HTX

$0.{5}2273

5.23%

SOL

$198.17

3.05%

BNB

$710

3.05%

简体中文

繁體中文

English

Tiếng Việt

한국어

日本語

ภาษาไทย

Türkçe

Partnered With:

Nghiên cứu｜Lịch sử tóm tắt về Lightning Network

Đọc bài viết này mất 63 phút

Khái niệm Lightning Network là thành công chỉ sau một đêm hay là một bước đột phá?

Nguồn gốc: Phòng thí nghiệm CYC

Tác giả gốc: Công nghệ CryptoYC

TL; DR

· Lightning Network là bậc thầy và đó là điều đúng đắn địa điểm và thời gian thích hợp.

· Những người tiền nhiệm của Lightning Network ít nhiều cần phải thực hiện các thay đổi đối với lớp BTC bên dưới, dẫn đến việc chúng không thể hoạt động tốt.

· Hiện được gọi là Cơ sở công nghệ sét (BOLT).

· Sau 19 năm, cơ sở hạ tầng Lightning Network ngày càng trưởng thành và sự phát triển tiếp theo sẽ tập trung vào tối ưu hóa và xây dựng sinh thái.

Khi nhắc đến Lightning Network, hầu hết mọi người chỉ nghe đến cái tên hoặc hiểu biết một chút về nó ... Nhiều người biết một số nguyên tắc cơ bản của nó hơn. Nhưng chúng ta cần suy nghĩ về một câu hỏi: Ý tưởng về Lightning Network là một thành công chỉ sau một đêm hay một kiệt tác? Ngay cả bằng trực giác, chúng tôi nghĩ đó là cái sau. Nhưng nó tích hợp những gì? Tại sao những ý tưởng có trước nó không được phát triển? Điều này đòi hỏi chúng ta phải xem lại lịch sử phát triển của Lightning Network. Từ thành phần của Lightning Network, không khó để nhận ra rằng cốt lõi của nó là kênh thanh toán và mạng thanh toán được tạo thành từ nó. Vì vậy, hôm nay chúng ta sẽ một lần nữa ôn lại những anh hùng đáng được tưởng nhớ này.

Kênh thanh toán - Hạt giống bằng mã BTC

Lightning Network Set Một trong những thành công lớn là các kênh thanh toán. Không có gì sai khi hiểu điều này bằng trực giác. Suy cho cùng, nếu muốn hình thành một mạng thanh toán ngang hàng, điều đầu tiên cần giải quyết là vấn đề thanh toán giữa các đồng nghiệp.

Ý tưởng cốt lõi của kênh thanh toán là thiết lập kênh giữa hai tài khoản Bitcoin. Mối quan hệ cân bằng giữa hai địa chỉ chỉ cần hai người biết, không cần tải lên chuỗi, chỉ cần phát một giao dịch lên chuỗi khi cả hai bên sẵn sàng giải quyết là đủ.

Sở dĩ nó được cho là “hạt giống” của Lightning Network hiện tại là vì về khái niệm của nó và BTC đã ra đời sớm hơn bao giờ hết. Phiên bản Bicoin 0.1 bao gồm bản nháp mã cho kênh thanh toán, cho phép người dùng cập nhật giao dịch trước khi giao dịch được mạng xác nhận.

Tất nhiên, giải pháp được xây dựng thông qua mã này vẫn còn rất thô sơ, nhưng Nakamoto sau đó đã trò chuyện riêng với nhà phát triển bitcoinj Mike Hearn để biết thêm chi tiết về kênh thanh toán và vào năm 2013, Hearn tiết lộ lời giải thích của Satoshi Nakamoto về các kênh thanh toán (như hiển thị bên dưới)

Tóm lại: nếu một giao dịch vẫn còn trong nhóm giao dịch Nếu nó vẫn còn không được đóng gói, người dùng có thể gửi một giao dịch mới. Số thứ tự của giao dịch này phải cao hơn số thứ tự của giao dịch cũ. Người khai thác nên ưu tiên đóng gói giao dịch có số thứ tự cao hơn. Điều này cho phép một người liên tục gửi giao dịch cho người khác và cập nhật số thứ tự, người khai thác chỉ cần đóng gói giao dịch có số thứ tự lớn nhất.

Đồng thời, một số khái niệm liên quan như:

· nLocktime, một lĩnh vực trong giao dịch BTC. Bất kỳ giao dịch nào chứa trường này, nếu giá trị của trường này là giá trị có ý nghĩa, chẳng hạn như 1000 khối, thì giao dịch chỉ có thể được đóng gói sau 1000 khối.

· signaturehash

· ……

Đã truyền cảm hứng cho một loạt ông lớn bắt đầu một loạt nỗ lực tiếp theo.

Hashcoin - ý tưởng về kênh thanh toán có thể sử dụng đầu tiên

Nhưng Chúng ta có thể thấy rằng trong cách giải thích cơ bản này, khó có thể tránh được vấn đề chi tiêu gấp đôi, tức là khó thực hiện nếu không có sự tin tưởng. Giả sử rằng người dùng trong kênh thanh toán và người khai thác thông đồng để khiến khối xác nhận một giao dịch cũ có lợi cho họ (các giao dịch trước đó trong nhóm giao dịch đều hợp pháp, vì vậy không chỉ giao dịch có số thứ tự cao nhất mới hợp pháp) , Khi đó Bạn có thể khiến người khác chịu lỗ và mang lại lợi ích cho bản thân và những người khai thác.

Vì vậy, dựa trên vấn đề này, vào ngày 4 tháng 7 năm 2011 (sau khi Satoshi Nakamoto biến mất), Người dùng Bitcointalk "hashcoin" đã thiết kế một kênh thanh toán cấu trúc hai lớp. Ý tưởng cốt lõi là yêu cầu gửi các giao dịch đa chữ ký và các giao dịch khóa thời gian hiệu quả phụ thuộc lẫn nhau (sử dụng trường nLocktime ban đầu của BTC). Nếu một Người tham gia biến mất và một người tham gia khác có thể rút toàn bộ số tiền trong kênh thanh toán sau khi khóa thời gian được mở khóa. Chúng ta có thể xem xét quy trình cụ thể để làm rõ tầm quan trọng của ý tưởng này cũng như tác động của nó đối với một loạt giải pháp tiếp theo.

Chúng ta có thể thấy rằng Hashcoin sử dụng một ý tưởng rất thông minh, cho phép người nhận trong kênh thanh toán ký giao dịch B trước tiên để có thể chi tiêu đầu ra trong kênh thanh toán của cả hai bên (một lần nữa, nhấn mạnh vào mô hình UTXO, không có số dư, chỉ Đầu ra và đầu vào, Một đầu vào phải được truy nguyên đến một đầu ra), sau đó cả hai bên ký vào giao dịch đầu ra A của kênh thanh toán. Trong khoảng thời gian này, khi người trả tiền muốn trả tiền cho người nhận, anh ta chỉ cần cập nhật giao dịch B (trình tự ban đầu của giao dịch B là 0 và bản cập nhật được tăng lên một lần). Cuối cùng, trước khi khóa băm hết hạn, người nhận phát sóng giao dịch B với số thứ tự lớn hơn.

Điều tuyệt vời nhất của ý tưởng này là nó giải quyết được vấn đề trong kênh thanh toán khi cả hai các bên không còn hợp tác Vấn đề không rút được tiền. Bởi vì nếu bạn muốn mở kênh, trước tiên bạn phải ký một giao dịch cho phép chuyển tiền trong kênh ra ngoài (trong trường hợp người nhận không muốn chơi với người trả tiền nữa, anh ta vẫn có thể lấy lại tiền của mình sau thời gian đó). lock được mở khóa, thay vì bị khóa trong kênh thanh toán), giao dịch chuyển tiền sẽ được ký.

Nhưng nhược điểm của ý tưởng này là:

· Toàn bộ kênh là một chiều. Bạn chỉ có thể gửi A đến B hoặc B đến A. Mặt khác, bạn phải mở một kênh mới, điều này rất bất tiện.

· Cách sử dụng các kênh thanh toán mà không biết người nhận là ai.

· nlocktime chỉ có thể chứng minh rằng có thể sử dụng một đầu ra trong tương lai chứ không chứng minh được rằng không thể sử dụng đầu ra trước khi hết hạn.

· Vì phương thức băm của BTC vào thời điểm đó yêu cầu chữ ký (trước segwit), nên để hoàn thành giao dịch B, tiền của giao dịch A cần phải được nhập trước, điều này đã hình thành nên một nghịch lý. Đây cũng là vấn đề về độ dẻo (dẻo) của BTC tương đối phổ biến vào thời điểm đó.

Và quan trọng hơn, hashcoin chỉ là ý tưởng và chưa có nỗ lực thực hiện.

Kênh thanh toán của Jeremy Spilman

Cho đến tháng 4 năm 2013, Jeremy Spilman đã nghĩ ra một khái niệm tương tự như hashcoin và đã viết mã chứng minh khái niệm. Vì ý tưởng do Jeremy đề xuất đã được mô tả thông qua danh sách gửi thư phát triển Bitcoin vào thời điểm đó nên không có tên rõ ràng. Sau đó, nó được tối ưu hóa bởi Mike Hearn (người tiết lộ mô tả của Satoshi Nakamoto về kênh thanh toán ở trên), cũng như người đóng góp cốt lõi Bitcoin, người đồng sáng lập blockchain, Matt Corallo (Chaincode Labs, một phòng thí nghiệm gồm các nhà phát triển BTC chuyên xây dựng BTC), v.v... Với nỗ lực của những người khác, người ta đã công bố vào ngày 27 tháng 6 năm 2013 rằng khái niệm này đã được thêm vào bitcoinj (thư viện phát triển BTC). Nhiều ứng dụng và dịch vụ Bitcoin được xây dựng trên đó, chẳng hạn như bisq.network, ví bitcoin , rsk.co, Cũng được tạo bởi Mike Hearn).

Nhưng chúng ta có thể thấy rằng một số thiếu sót của hashcoin vẫn chưa được giải quyết.

May mắn thay, vấn đề về nLocktime đã được giải quyết trong đề xuất BIP-0065 vào ngày 10 tháng 11 năm 2014 . Giải pháp là thêm trường OPCODE mới dưới dạng ngã ba mềm - CHECKLOCKTIMEVERIFY. Cho phép các giao dịch không khả dụng trước một thời điểm nhất định.

Tôi sẽ không đi sâu vào những thay đổi cụ thể. Tóm lại, việc thêm trường này sẽ tạo thành trường này Các kênh thanh toán theo chiều trở nên khả dụng về mặt lý thuyết (trong một số điều kiện nhất định).

Đề xuất kênh thanh toán 2 chiều

Bây giờ chúng ta sẽ không thảo luận về vấn đề phương pháp băm BTC. Tuy nhiên, vấn đề thanh toán một chiều có thể được tối ưu hóa mà không cần di chuyển lớp bên dưới. Vào ngày 7 tháng 10 năm 2014, Alex Akselrod (hiện là kỹ sư tại phòng thí nghiệm Lightning) lần đầu tiên đề xuất kênh thanh toán hai chiều. Ý tưởng cốt lõi là giới thiệu khóa thời gian giảm dần, cho phép người nhận gửi tiền cho người gửi với số lần giới hạn. Mặc dù kế hoạch này chưa bao giờ được thực hiện nhưng chúng ta vẫn có thể nhìn qua được suy nghĩ của Alex lúc đó.

Có thể thấy rằng cuộc thảo luận dựa trên đề xuất này xoay quanh việc dựa vào nLocktime để chuyển đổi vai trò thanh toán. Ví dụ: giả sử Alice và Bob xây dựng kênh thanh toán hai chiều. Thanh toán từ Alice tới Bob. Giả sử Alice chuyển 1 BTC cho Bob và đánh dấu nLocktime là 1000 trên giao dịch này. Sau đó, Bob có thể trả ngược lại BTC cho Alice, nhưng thời gian khóa của giao dịch do Bob thực hiện sẽ giảm từ 1000, chẳng hạn như 999 và Bob bắt đầu mỗi giao dịch of sẽ giảm nLocktime, vì vậy Bob chỉ có thể bắt đầu tối đa 1000 giao dịch.

Tại thời điểm này, ngoài vấn đề về tính dẻo (dẻo) của BTC, nền tảng của Kênh thanh toán đã bước đầu được hoàn thiện.

Mạng thanh toán - cách duy nhất để mở rộng kênh thanh toán

Lịch sử kênh thanh toán trên cơ bản đã kết thúc, tiếp theo chúng ta hãy nhìn vào mạng thanh toán. Nhìn lại kênh Thanh toán ở trên, bạn sẽ thấy toàn bộ kênh thanh toán được hình thành để tương tác giữa hai người. Tuy nhiên, nếu A và B có kênh thanh toán, B và C có kênh thanh toán thì A có thể trực tiếp thanh toán cho C không? (Nói cách khác đây chính là nhược điểm của Hashcoin nêu trên. Không biết đối thủ sử dụng kênh thanh toán như thế nào để tiến hành giao dịch nếu bên đó là ai?) Do đó, sau khi kênh thanh toán đầu tiên (hashcoin) được đề xuất, một số ông lớn đã xem xét mạng thanh toán ngoại tuyến. Có rất nhiều BTC như Petter Todd (người đề xuất BIP-0065 đã đề cập ở trên) và Gavin Andresen (người kế nhiệm phát triển BTC được Satoshi Nakamoto chỉ định vào thời điểm đó, nhưng sau đó bị cộng đồng đuổi ra ngoài vì tin vào Satoshi Nakamoto giả mạo). Nhà phát triển cốt lõi. Vậy họ phải làm việc đó như thế nào?

Suy nghĩ ban đầu

Tương tự như kênh thanh toán, nhiều ý tưởng về mạng thanh toán đã ra đời trước khi được đưa vào thực tế. Một trong những ý tưởng nổi tiếng hơn là các ngân hàng được liên kết với Fidelity: thanh toán phi tập trung, có thể kiểm toán, riêng tư, ngoài chuỗi, được đề xuất bởi Petter Todd từ nhóm nhà phát triển cốt lõi BTC vào ngày 23 tháng 2 năm 2013 và Gavin Andresen vào ngày 4 tháng 7 năm 2012. Off- các giao dịch chuỗi được đề xuất vào ngày 13 tháng 7 năm 2011 và Đề xuất giao dịch POS nhanh với Bitcoin được đề xuất bởi Corn Plooy (hiện là nhà phát triển Lightning Network và làm việc tại sàn giao dịch BL3P của Hà Lan) vào ngày 13 tháng 7 năm 2011.

Có thể tìm thấy thảo luận chi tiết về hai đề xuất đầu tiên trong các liên kết bên dưới. Nhưng về mặt khái niệm thiết kế, ý tưởng của cả hai rất giống nhau: về cơ bản họ giới thiệu một người trung gian bán tin cậy ("bán tin cậy" có nghĩa là mặc dù người trung gian không thể lấy cắp tiền của người dùng, nhưng người trung gian chọn không hợp tác, sau đó trong Không thể rút tiền của Mạng thanh toán) để thực hiện chức năng của mạng thanh toán ngoài chuỗi. Petter Todd đã thêm khái niệm về quyền riêng tư trên cơ sở này, trong khi ý tưởng của Gavin là giải quyết thuần túy vấn đề thanh toán.

Tuy nhiên, chúng ta cần nói riêng về giải pháp Plooy sớm nhất. Ý tưởng của nó phù hợp hơn với định nghĩa của chúng ta về mạng trong mạng thanh toán.

Mũi tên đen Đó là một quy trình chuyển BTC tiêu chuẩn, nhưng Plooy đã thêm phần mũi tên màu đỏ trên cơ sở này, đây là phần cốt lõi của mạng thanh toán ngoài chuỗi. Toàn bộ quá trình đại khái như sau:

1. Người mua bắt đầu giao dịch với người bán (ở định dạng thông tin được chuẩn hóa);

2. Đồng thời, người mua sẽ công bố giao dịch lên mạng BTC và thực hiện 6789 bước xác nhận thông thường;

3. Người mua cũng sẽ gửi giao dịch đến "Mạng xác minh nhanh" trên cơ sở này;

4. Các nút của "Mạng xác minh nhanh" sẽ là dựa trên Dữ liệu gốc nhanh chóng xác minh giao dịch;

5. Mạng xác minh nhanh sẽ thông báo cho người bán về kết quả phát hiện sơ bộ trong vòng vài giây;

6. Việc thanh toán cuối cùng (xác minh) vẫn được xác minh thông qua mạng BTC cổ điển. Nếu xảy ra sự cố chi tiêu gấp đôi, các nút trong mạng xác minh nhanh sẽ bồi thường thiệt hại cho người bán.

Như bạn có thể thấy từ hình trên, ý tưởng của Plooy là xây dựng một lớp mạng thanh toán nhanh trên mạng BTC truyền thống. Vì vậy, cốt lõi ở đây nằm ở lớp mạng lưới giải quyết nhanh chóng này. Vì những tổn thất do các vấn đề như chi tiêu gấp đôi được thanh toán bởi các nút trong mạng thanh toán nhanh nên cần có một cơ chế giải trình trách nhiệm rõ ràng. Trong thiết kế của Pooly, hệ thống trách nhiệm giải trình này dựa trên chữ ký nút xác minh mà người bán nhận được ở bước 5. Điều này cho thấy các nút trong mạng xác minh nhanh không được liên kết ngẫu nhiên như các nút BTC mà chỉ khi hai nút tin cậy lẫn nhau thì liên kết sẽ được thiết lập và sau đó trách nhiệm có thể được truy tìm từng lớp và cuối cùng được truy tìm đầu của người mua thiết bị đầu cuối. Đồng thời, hệ thống trách nhiệm giải trình này yêu cầu người mua cuối phải thanh toán trước khi tham gia mạng xác minh nhanh.

Có thể thấy suy nghĩ của Plooy vẫn sẽ dựa vào sự tin tưởng. Nó không hoàn toàn không đáng tin cậy. Nhưng để cho ra đời thiết kế này vào năm 2011 thì quả là đáng chú ý. Đồng thời, nó cũng cung cấp tài liệu tham khảo tốt cho một số dự án thực tế tiếp theo.

Amiko Pay - tiền thân của Lightning Network

Giống như hashcoin, Plooy không triển khai nó một cách cụ thể ngay từ đầu, nhưng trong giai đoạn này, mọi người đã cố gắng cải thiện ý tưởng, bao gồm các nhà phát triển cốt lõi BTC và Gregory Maxwell (CTO blockchain) và Ryan Fugger (Người sáng lập Ripple ) et al. Cuối cùng, vào ngày 22 tháng 7 năm 2012, một bài viết Kết hợp Bitcoin và Ripple để tạo ra một mạng thanh toán nhanh, có thể mở rộng, phi tập trung, ẩn danh, độ tin cậy thấp (dự thảo 1) đã công bố sự ra đời của Amiko Pay.

Amiko Pay có thể được coi là nỗ lực của Plooy để triển khai nó. Tuy nhiên, trong phiên bản dự thảo này, Kênh thanh toán không được sử dụng nên toàn bộ mạng vẫn yêu cầu sự tin cậy: nếu người dùng từ chối thanh toán số dư với người dùng khác thì người dùng sau sẽ không có quyền truy đòi. Mặc dù bản thảo của ấn bản thứ hai được phát hành vào ngày 15 tháng 1 năm 2013 nhưng nội dung của nó không có thay đổi đáng kể.

Amiko Pay đã thực hiện nhiều thay đổi kể từ đó và cuối cùng (2015) đã thiết kế ra một giải pháp không cần sự tin cậy. Tuy nhiên, do những hạn chế của mô hình lập trình BTC lúc đó thời gian, Do những hạn chế, các giải pháp tương tự rất khó thực hiện và yêu cầu những thay đổi "nhất định" đối với BTC, và cuối cùng không có gì xảy ra. Amiko Pay cập nhật tiến trình lộ trình lần cuối vào tháng 6 năm 2016:

Nếu bạn quan tâm hơn đến Amiko Pay, ngoài các siêu liên kết đính kèm với bài viết này, bạn cũng có thể nhấp vào trang chủ của họ để tìm hiểu thêm: https://cornwarecjp.github.io/amiko-pay/.

Tuy nhiên, như đã viết ở trên, bản thân Amiko Pay không kết hợp tốt các ưu điểm của Kênh thanh toán nên là một số cơ hội cho những người khác cuối cùng đã biến thành làn sóng phía trước.

Các giải pháp khác để kết hợp kênh thanh toán và mạng thanh toán

Mặc dù phe Amiko Pay không kết hợp tốt lắm việc thiết kế các kênh thanh toán nhưng ngay từ năm 2012, đã có người đề xuất ý tưởng kết hợp cả hai. Vào ngày 5 tháng 7 năm 2012, Meni Rosenfeld đã đề xuất một ý tưởng về thanh toán Bitcointalk, Trustless, tức thời, ngoài chuỗi, bổ sung thêm vai trò của người chuyển tiếp cho Hashcoin để hình thành một khoản thanh toán đơn giản bao gồm các kênh thanh toán trên mạng. Bằng cách này, bạn chỉ cần thiết lập kênh thanh toán bằng "rơle" và sau đó liên kết những người dùng khác thông qua rơle. Cần lưu ý ở đây rằng vai trò của người chuyển tiếp cũng không kiểm soát ví của bất kỳ ai mà chỉ chịu trách nhiệm thiết lập kênh. Đồng thời, những người chuyển tiếp được phép cạnh tranh việc làm để tiếp tục phân tán vốn, dù có vấn đề gì cũng chỉ bị thất thoát một phần nhỏ. Tất nhiên, điều này cũng đòi hỏi người dùng phải tin tưởng vào người chuyển tiếp.

Tất nhiên, những ý tưởng tương tự đã liên tục xuất hiện trong vài năm qua. Ví dụ: Petter Todd, người đã được nhắc đến nhiều lần, đã đề cập đến một khái niệm tương tự (giao dịch có phí gần như bằng 0 với các khoản thanh toán vi mô trung tâm và nan hoa) trong nhóm gửi thư của nhà phát triển BTC vào tháng 12 năm 2014, cũng đề cập đến sự đồng thuận được nhúng của các đồng tiền màu. Plan), thậm chí trước đó vào năm 2013, Alex Akselrod đã đề xuất một dự thảo tương tự và phát hành mã thử nghiệm vào cuối năm 2014. . Bitpay (cung cấp dịch vụ thanh toán BTC, người dùng thanh toán BTC và người bán có thể nhận đô la Mỹ, giảm rủi ro biến động) cũng đưa ra sách trắng khái niệm tương tự "Impulse" và kế hoạch triển khai thực tế vào năm 2015. Tất nhiên, cũng có những công ty như Strawpay. đã làm điều này Stroem, chờ đã.

Chúng tôi có thể nghĩ rằng mỗi giải pháp trên, cho dù đó là Amiko Pay, Impulse hay Storem, đều có thể triển khai Lightning Network những chức năng đó. Tuy nhiên, liệu họ có cần thực hiện những thay đổi "lớn hơn" đối với BTC hay không ("lớn hơn" ở đây có thể là một vấn đề rất đơn giản trên các chuỗi công khai khác, nhưng trên BTC, bất kỳ sự thay đổi nào cũng rất khó khăn. Có một câu như người ta thường nói, " Mọi thay đổi thành công trên BTC đều là giấy tờ") hoặc yêu cầu phải thỏa hiệp ở một số khía cạnh. Vì vậy, những người nghĩ ra những kế hoạch này trong thời đại đó và cố gắng hết sức để thực hiện chúng vốn đã rất mạnh mẽ nhưng vẫn chưa đủ, phải có nhiều người tài năng hơn nữa mới có thể thể hiện tài năng của mình trong giới hạn của BTC.

Thanh kiếm đang tới! --Lightning Network chính thức ra mắt

Nhiều anh hùng trước đó đã trở thành khói và gương, nhưng những vấn đề còn lại vẫn cần được giải quyết. Vì vậy trước khi nhân vật chính xuất hiện, chúng ta hãy cùng điểm qua những vấn đề còn tồn tại của mạng lưới thanh toán và các kênh thanh toán hiện tại.

· Làm sao mà không có niềm tin?

· Làm cách nào để thực hiện những thay đổi tối thiểu đối với mạng BTC?

Vấn đề đầu tiên về cơ bản là do vấn đề thứ hai gây ra. Một giải pháp tốt hơn. Sau đó, câu hỏi đặt ra là làm thế nào để triển khai mạng thanh toán hiệu quả BTC không cần sự tin cậy trong các ràng buộc của mô hình lập trình BTC.

Đã có rất nhiều sự tích lũy công nghệ trong quá khứ và vào năm 2015, cuộc thảo luận về Sự mở rộng trong cộng đồng BTC ngày càng trở nên nóng bỏng nên chúng tôi nhận thấy nhiều bước đột phá quan trọng đã ra đời vào năm đó (thậm chí trước khi xuất hiện sách trắng Lightning Network theo nghĩa hẹp, blockchain đã được thiết lập để nghiên cứu những thứ trong các lĩnh vực liên quan ). Trong số đó, bài báo “Mạng thanh toán nhanh và có thể mở rộng với các kênh thanh toán vi mô song công Bitcoin” của Viện Công nghệ Zurich đã được phát hành vào cuối năm 2015. Giải pháp của bài báo chủ yếu dựa vào khóa thời gian như một "thiết bị đếm ngược" về tính hợp lệ của kênh và kỹ thuật mã hóa được gọi là "cây vô hiệu" để vô hiệu hóa các giao dịch kênh cũ. Đây cũng trở thành công nghệ nguyên mẫu mà Lightning Network sau này dựa vào. Hai tác giả của bài báo này, Christian Decker và Roger Wattenhofer, sau đó đã tham gia vào blockchain.

Thời gian, địa điểm và sự hòa hợp, nếu cả ba không phù hợp thì dù có thắng cũng sẽ gặp thảm họa - "Sun Bin's Art of War: Moon War"

Việc mở rộng BTC ngày càng trở nên phổ biến vào năm 2015 (hai hội nghị mở rộng nổi tiếng đã được tổ chức vào năm 2015, Scaling Bitcoin Montreal vào tháng 9 và Scaling Bitcoin Hong Kong vào tháng 12). Ngày này là Tianshi. Sự tích lũy trước đó của nhiều công nghệ và hai thiết kế chủ chốt được đề xuất trong bài báo đó đã mở đường cho Lightning Network, đây là một vị trí đắc địa.

Sau đó, đã có đúng thời gian và địa điểm, tất cả những gì còn lại là một người và đúng người. Có lẽ đây là nhân vật chính. Vào cuối năm 2015, Gregory Maxwells, một trong những nhà phát triển cốt lõi của BTC, đã tóm tắt các cuộc thảo luận gần đây về việc mở rộng BTC (Tăng công suất cho hệ thống Bitcoin, về cơ bản là trọng tâm của cộng đồng BTC vào thời điểm đó). . Ý nghĩa), trong đó có chứa một đoạn của Lightning Network. Và anh ấy là một trong những thành viên sáng lập của blockstream vào thời điểm đó. Về thành tích của Maxwells, bạn có thể đọc một bài báo khoa học phổ biến: https://academy .bit2me .com/en/who-is-gregory-maxwell/.

Tóm lại, đối với Lightning Network, đúng địa điểm, đúng thời điểm và đúng người sẽ kết hợp với nhau . Đây là màn trình diễn của nó Đã đến lúc rồi! (Bản thảo đầu tiên của "Mạng Lightning Bitcoin: Thanh toán tức thì ngoài chuỗi có thể mở rộng" đã được phát hành tại Hội thảo phát triển BTC ở San Francisco vào ngày 23 tháng 2 năm 2015).

Tiếp theo, chúng ta hãy xem mạng Lightning tốt hơn những người tiền nhiệm của nó như thế nào ? Chúng ta sẽ xem xét nó từ hai góc độ tối ưu hóa.

Kênh thanh toán (gọi là kênh Poon-Dryja trong Lightning Network)

· Lightning Network sẽ Khoảng thời gian của cả hai bên được mở rộng đến không giới hạn. Kênh này luôn có thể tồn tại miễn là cả hai bên đều sẵn lòng. Giải pháp kênh thanh toán trước đó cần phải đóng trước khi hết thời gian nlocktime (nếu không sẽ tự động giải quyết)

· Thanh toán hai chiều là không giới hạn.

Mạng thanh toán

· Sử dụng HTLC (Hash Time Lock) để kết nối các Kênh với nhau tạo thành mạng lưới. Điều này có nghĩa là gì? Những điều kiện khác bao gồm hai điều kiện "HOẶC".

· Tạo một khoản thanh toán có điều kiện, ví dụ A đưa cho B một khoản tiền và B cần giải quyết một vấn đề để tiêu số tiền đó (phải là B, không phải bất kỳ người nào). Nghĩa là, người được trả tiền tiết lộ một phần thông tin và cung cấp bằng chứng về thông tin này để tiêu tiền. Một định nghĩa chặt chẽ hơn là: khóa khóa bí mật băm. Dựa trên tính chất một chiều của hàm băm, giá trị băm của một bản mã có thể được đưa vào đầu ra của giao dịch để hoạt động như một khóa bản mã băm, nghĩa là giá trị băm phải được nhập. Chỉ có văn bản mã hóa tương ứng mới có thể mở khóa Bitcoin trong tập lệnh. Ví dụ: nếu Alice nhận được chuyển khoản 2BTC, nhưng bên kia đặt khóa giá trị băm, Alice phải lấy được bản mã của bên giao dịch và hợp tác với chữ ký khóa của chính mình để ký giao dịch và chi BTC để chuyển cho Bob.

· Bạn không thể tiêu tiền bên trong cho đến khi hết thời gian quy định. Trước thời điểm này, giao dịch không có hiệu lực và không thể thực hiện được. Một định nghĩa chặt chẽ hơn là đặt đồng hồ trong tập lệnh giao dịch. Bạn phải đợi thời gian đã đặt trước khi có thể sử dụng chữ ký khóa riêng của địa chỉ để mở khóa Bitcoin trong địa chỉ. Ví dụ: Alice đã nhận được chuyển khoản 2 BTC, nhưng bên kia đặt cần 1.000 khối để mở khóa, vì vậy Alice phải đợi 1.000 khối trước khi có thể ký giao dịch bằng khóa riêng của mình và chi BTC để chuyển cho Bob.

Vậy Lightning Network thực hiện điều đó như thế nào? Chúng tôi cũng biết từ thiết kế trước rằng làm thế nào để đảm bảo tính trung thực trong kế toán của cả hai bên là một bài toán khó mà Lightning Network cần phải giải quyết. Ở đây có hai điều liên quan:

·Làm sao để biết ai đang làm điều ác

·Làm điều ác thì bị trừng phạt như thế nào

· p>

Tại thời điểm này, chúng ta cần xem xét cách thực hiện một số lần chuyển tiền của Lightning Network trong kênh thanh toán. Bạn có thể tham khảo sách trắng để biết quy trình và nguyên tắc cụ thể.

Hôm nay chúng ta chủ yếu nói về lịch sử nên tôi sẽ tóm tắt nguyên tắc: Giả sử A và B Một kênh Lightning Network được xây dựng và đối với mỗi giao dịch, 4 bằng chứng giao dịch thực sự được tạo ra:

·Hồ sơ chuyển khoản được ghi trong sổ cái A

·Chuyển hồ sơ ghi trong sổ cái B

·Các bản ghi ghi trong sổ cái A để hủy giao dịch trước đó

· Bản ghi được ghi vào sổ cái B để vô hiệu hóa giao dịch trước đó

Chúng ta có thể thấy rằng bốn bằng chứng này thực chất được chia thành hai loại. Tuy nhiên, cần lưu ý rằng các bằng chứng của cùng một loại giao dịch ghi trên sổ cái của A và B là khác nhau.

· Giả sử A chuyển một BTC cho B. Lúc này tổng sổ cái là A: 4 B: 6. Lúc này ghi vào sổ cái của A và sổ cái của B nội dung phân phối BTC nhất quán, mâu thuẫn là để phân biệt giao dịch độc hại với ai gửi khi làm điều ác nên lập bài trên các thông tin khác cấu thành giao dịch. Giả sử một giao dịch khác xảy ra và A chuyển 1 BTC cho B. Bản ghi giao dịch tại thời điểm này phải là A:3 B:7, nhưng A muốn làm điều ác và gửi giao dịch cuối cùng đến chuỗi trước. Mạng Ở đây có thiết kế thú vị. Trong giao dịch (A:4 B:6) do A gửi, 6 BTC của B có thể được B rút ngay lập tức, nhưng 4 BTC của A phải đợi khóa thời gian băm hết hạn. cách để nạn nhân có thời gian phản ứng.

· Tại thời điểm này, bản ghi được sử dụng để hủy giao dịch trước đó sẽ rất hữu ích. Giả sử B phát hiện ra hành vi ác ý của A thì có thể gửi ngay bản ghi giao dịch mới nhất và bản ghi vô hiệu giao dịch trước đó về chuỗi. Vì A trước đó đã gửi giao dịch của 4 và 6 vào chuỗi nên B có thể lấy ngay 6 BTC của mình và khi đó tác dụng của việc vô hiệu hóa bản ghi trước đó là cho phép B có được ngay A, người ban đầu phải đợi khóa thời gian để 4 BTC tương đương 10 BTC trong toàn bộ kênh đều thuộc về B, A bị phạt.

Để liên kết các kênh khác nhau vào mạng, HTLC ở trên được sử dụng. Giả sử A muốn chuyển tiền cho C thông qua B. Quá trình này có thể được tóm tắt đơn giản như sau:

· C băm một bản mã thành A và A tạo một giao dịch cho B, nhưng giao dịch này yêu cầu B phải lấy C bản mã có thể được mở khóa. Nếu nó không được mở khóa trong ngày hết hạn, tiền sẽ được trả lại cho A.

· Sau đó, B xây dựng một giao dịch cho C, giao dịch này cũng yêu cầu bản mã C của C để mở khóa giao dịch. Bằng cách này, khi C nhận được tiền thì B cũng sẽ biết bản mã của C và có thể lấy được tiền của A.

Đây là quy trình chung của Lightning Network, tôi chỉ đề cập sơ qua, nếu cần tôi sẽ giải thích chi tiết sau. Hãy tiếp tục nói về lịch sử phát triển của Lightning Network.

Một số kế hoạch triển khai cụ thể

Bây giờ đã có sách trắng, vấn đề là thực hiện. Chúng tôi đã nói về vấn đề linh hoạt của BTC trước đây (ID giao dịch của B cần HASH giao dịch của A và HASH giao dịch của A cần chữ ký tương ứng. Tuy nhiên, trước đó chúng tôi đã nói rằng để mở kênh trên Lightning Network, chúng tôi cần xây dựng giao dịch của B đầu tiên, sau đó xây dựng A. Đây là vấn đề được trích dẫn từ nghịch lý trên). Để giải quyết vấn đề này, sách trắng của Lightning Network đã đề cập đến signaturehash-withoutinput form để giải quyết (nói tóm lại là nó bỏ qua đầu vào và chỉ ký đầu ra), nhưng cuối cùng lại không thành công. được sử dụng để đạt được mục đích tương tự.

Hơn nữa, không chỉ vậy, vì phiên bản đầu tiên của sách trắng chứa nhiều khái niệm kỹ thuật, ít người có thể hoàn toàn có thể hiểu được. Nhưng sau khi Rusty Russell, một nhà phát triển nhân hệ thống Linux lâu năm, nghiên cứu sách trắng này, hiểu biết cơ bản của mọi người đã được cải thiện rất nhiều. Trong một loạt blog vào đầu năm 2015, Russell đã “dịch” sách trắng cho nhiều đối tượng hơn (nhưng nó vẫn khá khiêu khích). Vào tháng 3 cùng năm, Russell được mời tham gia Blockstream và phát triển triển khai đầu tiên của Lightning Network: C-lightning. Sau đó, Christian Decker của Blockstream đã tham gia cùng Russell; những người khác, bao gồm Corn Plooy, cũng đóng góp cho dự án nguồn mở.

Ngay sau đó, một công ty nhỏ có tên ACINQ đã tham gia nghiên cứu về Lightning Network. Vào ngày 22 tháng 3, có thông báo rằng họ đã viết giao thức Lightning Network-eclair của riêng mình bằng Scala.

Nhưng còn Lightning Lab mà chúng ta biết rõ thì sao? Chà, họ được thành lập vào tháng 1 năm 2016 bởi Poon và Dryja, hai trong số các tác giả của sách trắng Lightning Network. Sau đó mọi người phát hiện ra rằng họ đã làm LND. Và vào cuối năm 2016, Dryja rời Lightning Labs và đến dự án tiền kỹ thuật số của MIT để tạo ra LIT tương tự LND (điểm khác biệt giữa cả hai là nó gói gọn ví và nút thành một tổng thể và hỗ trợ nhiều loại tiền tệ cùng một lúc ).

Đồng thời, do vấn đề về khả năng mở rộng, công ty khai thác nổi tiếng Bitfury đã chia tách lnd và We đã cân nhắc vấn đề về khả năng mở rộng và xây dựng Lightning Network có thể được sử dụng ngay cả khi không giải quyết được vấn đề về khả năng mở rộng BTC. Nhưng hiện tại dự án đang bị đình trệ.

Sau đó, Blockchain (công ty ví) đã phát triển một phiên bản đơn giản hóa của Lightning Network có tên là Thunder, công ty này đã tung ra một phiên bản thực tế của Lightning Network với chi phí "không cần sự tin tưởng". Lightning Network sớm nhất trên Internet - phiên bản alpha của Thunder. Mặc dù bây giờ không có âm thanh.

Có thể thấy rằng vào thời điểm đó có rất nhiều mạng lưới sét khác nhau nên vào thời điểm này, luôn có Sẽ có cuộc họp để điều chỉnh mọi người để mọi người có thể giao tiếp với nhau. Hội nghị này là ba hội nghị Scaling Bitcoin Milan được tổ chức vào tháng 10 năm 2016. Tại cuộc họp này, các bên tham gia dự án khác nhau đã đạt được tính nhất quán về khả năng tương tác và đưa ra đặc tả giao thức Lightning Network (Cơ sở công nghệ Lightning) có tên là "BOLT". Do đó, về mặt lý thuyết, sách trắng của Lightning Network là tài liệu đầu tiên và BOLT là nền tảng của Lightning Network thực tế mà chúng ta biết ngày nay.

Hướng tới khả năng sử dụng

Đối với mạch câu chuyện khác, nó xoay quanh tính linh hoạt của Bitcoin. Từ CLTV (CheckLockTimeVerify) do Petter Todd đề xuất vào năm 2015, đến việc triển khai khóa thời gian tương đối (CSV, CheckSequenceVerify), cho đến nâng cấp tiếp theo của segwit, Lightning Network cuối cùng đã bước vào giai đoạn ứng dụng. Ví dụ đầu tiên về việc sử dụng chính thức Lightning Network là trên mạng thử nghiệm segwit. Vào tháng 10 năm 2016, chưa đầy nửa năm sau khi segNet được triển khai, Decker của blockstream đã sử dụng c-lighting để mua một "con mèo" từ Russell.

Đây còn được gọi là "Đèn flash đầu tiên của Lightning Network."

Sau đó vào tháng 1 năm 2017, LND tung ra phiên bản alpha. Phải đến mùa hè năm 2017, SegWit mới chính thức được kích hoạt. Blockstream đã công bố giao dịch Lightning trên mạng chính BTC đầu tiên 3 tháng sau đó và vào tháng 11, Lightning Labs đã thực hiện giao dịch Lightning xuyên chuỗi khối đầu tiên (từ Bitcoin sang Litecoin). Vào tháng 12, các nhóm phát triển từ Blockstream, Lightning Labs và ACINQ đã thông báo rằng họ đã vượt qua thử nghiệm khả năng tương tác.

Càng về cuối năm, kênh sét mở ra ngày càng nhiều. Đến tháng 12, nhà phát triển Alex Bosworth đã sử dụng kênh Lightning Network để thanh toán hóa đơn điện thoại di động của mình cho bộ xử lý thanh toán Bitrefill: một trong những giao dịch đầu tiên trên Lightning Network sử dụng Bitcoin làm tiền.

Một tháng sau, Blockstream mở một cửa hàng trực tuyến nơi mọi người có thể sử dụng Bitcoin để mua hàng hóa vật chất - mặc dù việc triển khai c-lightning vẫn là phiên bản beta. Vào tháng 2 năm 2018, khi Lightning Network vẫn còn ở giai đoạn alpha, Lazlo Hanyecz, một huyền thoại trong thế giới Bitcoin và nổi tiếng thế giới với giai thoại “mua pizza bằng bitcoin”, đã tuyên bố rằng ông đã mua pizza bằng Lightning Network.

Câu chuyện sau đây diễn ra suôn sẻ. Nhiều giải pháp Lightning Network khác nhau đã được triển khai lần lượt và hệ sinh thái liên quan cũng đang được cải thiện từng ngày. Đây là những sự kiện lịch sử mà cá nhân tôi cảm thấy là quan trọng đối với Lightning Network cho đến nay.

Tóm tắt

Tóm tắt thứ nhất: trí thông minh của thiên tài bao giờ cũng “vô giá trị”.

Nếu bạn nhìn vào những hành động liên quan của hai tác giả trong sách trắng của Lightning Network, bạn có thể rút ra kết luận Kết luận thứ hai: Những thiên tài luôn khiến mọi việc xảy ra.

Những thành tựu chính của hai bên như sau:

Thaddeus Dryja, đã làm việc trong một dự án có tên mirro, một hệ thống giao dịch ngang hàng và bổ sung thêm khái niệm về thị trường dự đoán. Đồng thời, thuật toán PoW (Hashimoto) cũng được phát triển, tiền thân của thuật toán thay thế (Dagger Hashimoto) trước khi thuật toán Ethereum PoW ethash được ra mắt: http://diyhpl.us/~bryan/papers2/bitcoin/meh/hashimoto.pdf.

Một tác giả khác, Joseph Poon, cũng là một trong những tác giả của plasma. Mạng Lightning dựa trên kênh đã được đề xuất bằng BTC và plasma dựa trên chuỗi được đề xuất bằng Ethereum. Đồng thời, chúng tôi cũng thực hiện handshake (https://handshake.org/), một dự án kế thừa ý tưởng namecoin. Tất nhiên, việc có cắt giảm ai đó hay không nằm ngoài phạm vi thảo luận của chúng ta.

Cuối cùng, đây là dòng thời gian của chúng tôi về các sự kiện lớn liên quan đến Lightning Network:

Nguồn hình ảnh: Sắp xếp CYC

Tham khảo tài liệu:

https://github.com/bitcoin/bips/blob/master/bip -0065.mediawiki

https://bitcoinmagazine.com/Technology/history-lightning-brainstorm-beta

https://điện áp.cloud/blog/bitcoin-lightning-network /life-of-lightning/

https://en.wikipedia.org/wiki/Lightning_Network

https://bitcointalk.org/index.php?topic=146307.0

http://gavintech.blogspot.com/2012/07/off-chain-transactions.html

https://bitcointalk.org/index.php?topic=28565. msg359408#msg359408

http://www.ultimatestunts.nl/bitcoin/ripple_bitcoin_draft_1.pdf

https://bitcointalk.org/index.php?topic=91732.msg1010405# msg1010405

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-December/006988.html

https://en.bitcoin.it/wiki/ Người dùng:Aakselrod/Bản nháp

https://www.strawpay.com/docs/stroem-Payment-system.pdf

https://tik-old.ee.ethz. ch/file//716b955c130e6c703fac336ea17b1670/duplex-micro Payment-channels.pdf

https://montreal2015.scalingbitcoin.org/

https://lists.linuxfoundation.org/pipermail/ bitcoin-dev/2015-December/011865.html

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

https: //lightning.network/lightning-network-paper.pdf

https://github.com/mpegavi/bitcoincn/blob/master/%E6%AF%94%E7%89%B9%E5 %B8%81%E9%97%AA%E7%94%B5%E7%BD%91%E7%BB%9C%E7%99%BD%E7%9A%AE%E4%B9%A6%EF%BC %9A%E5%8F%AF%E6%89%A9%E5%B1%95%E7%9A%84%20ngoài chuỗi%20%E5%8D%B3%E6%97%B6%E6%94%AF %E4%BB%98%EF%BC%88%E4%B8%AD%E6%96%87%EF%BC%89.pdf