Liên kết gốc:

Liên kết gốc:

https://bitcoinops.org/en/topics/soft-fork-activation/

Kích hoạt ngã ba mềmĐề cập đến thời điểm khi một nút đầy đủ của Bitcoin bắt đầu thêm một hoặc nhiều quy tắc đồng thuận. Quá trình chuyển đổi này tạo ra rủi ro phối hợp giữa các nút. Do đó, các nhà phát triển đã dành nhiều nỗ lực trong nhiều năm để tạo và cải thiện cơ chế kích hoạt soft fork nhằm giảm thiểu khả năng xảy ra sự cố.

lịch sử

lịch sử

tiêu đề phụ

[2009] Chiều cao được mã hóa cứng: Đã bật lớp đồng thuận nLockTime

Soft fork được biết đến sớm nhất đã được triển khai trong phiên bản phần mềm Bitcoin 0.1.6 (phát hành vào tháng 11 năm 2009), được mã hóa cứng để kích hoạt ở độ cao khối 31000 và thời gian thực tế là ngày 22 tháng 11 năm 2009. Chiều cao kích hoạt được mã hóa cứng này đã được sử dụng trong ít nhất một đợt ngã ba mềm đầu tiên khác khi hầu hết công việc phát triển được thực hiện bởi Satoshi Nakamoto.

[2011] Thời gian được mã hóa cứng và can thiệp thủ công: BIP12OP_EVAL không thành công

Sau khi Satoshi Nakamoto rời Bitcoin, mã soft fork đầu tiên được hợp nhất vào Bitcoin là BIP12OP_EVAL. Kế hoạch ban đầu là sử dụng thời gian mã hóa cứng và can thiệp thủ công khi có ít hơn 50% sức mạnh tính toán hỗ trợ thay đổi. Trích dẫn từ BIP12:

[...] khách hàng và thợ đào mới sẽ hiểu OP_EVAL là không hoạt động cho đến ngày 1 tháng 2 năm 2012. Trước đó, những người khai thác được hỗ trợ có thể viết "OP_EVAL" trong các khối mà họ tạo ra, điều này thuận tiện cho chúng tôi trong việc tính toán tỷ lệ sức mạnh tính toán được hỗ trợ. Nếu không có hơn 50% hỗ trợ cho thay đổi này trước ngày 15 tháng 1 năm 2012, quá trình kích hoạt sẽ bị trì hoãn cho đến khi có hơn 50% hỗ trợ cho OP_EVAL (nếu rõ ràng là hầu hết hỗ trợ sẽ không kích hoạt nâng cấp này, quá trình nâng cấp sẽ bị hủy).

Can thiệp thủ công có thể là cần thiết vì OP_EVAL được phát hiện có lỗ hổng nghiêm trọng sau khi mã kích hoạt được hợp nhất nhưng trước khi nó được triển khai. Trong khi lỗi đã được sửa, một số nhà phát triển lo ngại rằng có thể có các vấn đề khác với opcode mới mạnh mẽ này, vì vậy mọi người đã từ bỏ soft fork.

[2012] Một nỗ lực khác về thời gian mã hóa cứng và can thiệp thủ công: BIP16 P2SH

Có một số đề xuất đơn giản hóa để thay thế OP_EVAL (xem BIP13/16, 17, 18 và 19, trong số các ý tưởng khác). Và BIP13/16 Pay to Script Hash (P2SH) đã giành được sự ủng hộ của hầu hết các nhà phát triển. P2SH sử dụng cơ chế kích hoạt giống như OP_EVAL. Thời gian kích hoạt theo kế hoạch ban đầu là ngày 1 tháng 3 năm 2012, nhưng đến ngày thanh toán là ngày 15 tháng 2, chưa đến 50% số người khai thác trong 100 khối cuối cùng cho biết họ sẽ thực hiện các quy tắc BIP16 trước tháng 3. Điều này dẫn đến một "chuỗi thay thế khá dài" (tách chuỗi), vì một số công cụ khai thác vẫn đang triển khai BIP16 vào ngày 1 tháng 3 đã từ chối các khối từ phần lớn các công cụ khai thác (những người không thực hiện các quy tắc mới). Ngày bỏ phiếu thứ hai diễn ra sau đó vài nghìn khối, vào ngày 15 tháng 3; lần này nó đã có đủ sự hỗ trợ. Vì vậy, nhà phát triển đã phát hành Bitcoin 0.6.0 vào ngày 30 tháng 3 và đặt thời gian kích hoạt vào ngày 1 tháng 4.

[2012] Thời gian mã hóa cứng: BIP30 từ chối sao chép txid

Sau khi hoàn tất kích hoạt P2SH, có thể thấy rằng nhiều giao dịch có thể chia sẻ cùng một txid. Về bản thân, lỗi này sẽ đơn giản khiến tiền của những người dùng cố gắng khai thác lỗi bị phá hủy, nhưng nó cũng có thể được kết hợp với một số hành vi kỳ quặc trong cấu trúc cây Merkle của Bitcoin để phá vỡ sự đồng thuận giữa các nút (xem CVE-2012-2459) . Ngã ba mềm đầu tiên khắc phục lỗ hổng này là BIP30, chỉ đơn giản là đánh dấu các giao dịch tiếp theo có cùng txid là không hợp lệ nếu giao dịch trước đó có đầu ra chưa được chi tiêu. Bản sửa lỗi này không gây tranh cãi giữa nhóm phát triển, vì vậy nó đã được kích hoạt với thời gian mã hóa cứng trong Bitcoin 0.6.0 bao gồm tham số kích hoạt P2SH.

[2012] IsSuperMajority (ISM): tiền tố cơ sở tiền xu BIP34

Mặc dù BIP30 khắc phục sự cố ngắn hạn do chồng chéo txid gây ra, nhưng các nhà phát triển Bitcoin biết rằng đây là một biện pháp tạm thời và không có lý do gì để phần mềm tìm kiếm chỉ mục của tất cả các giao dịch có đầu ra chưa sử dụng mỗi khi nhận được một giao dịch mới. Vì vậy, một giải pháp thứ hai đã được đề xuất, nhằm mục đích loại bỏ điểm yếu khiến sao chép txid trở thành một vectơ tấn công thực tế. Đây là BIP34. Đối với bản cập nhật này, các nhà phát triển đã sử dụng phương thức bỏ phiếu của người khai thác tương tự như BIP16 P2SH, nhưng lần này, những người khai thác sẵn sàng hỗ trợ EIP34 cần tăng giá trị nVersion cho các khối của họ. Hơn nữa, các nhà phát triển đã tự động thực hiện các quy tắc mới trong mã Bitcoin, vì vậy họ có thể phát hành phần mềm hỗ trợ soft fork trong khi chờ đợi các thợ đào nâng cấp. Quy tắc này từ BIP34 được thực hiện với một chức năng gọi là IsSUperMajority(). Lúc đầu, nó chứa một ngưỡng kích hoạt duy nhất và khi đạt đến ngưỡng đó, các quy tắc đồng thuận mới của BIP34 bắt đầu được triển khai:

Quy tắc 75%: Nếu 75% trong số 1000 khối mới nhất là tầm nhìn2 hoặc lớn hơn, hãy bắt đầu từ chối các khối tầm nhìn 2 không hợp lệ

Trong quá trình phát triển tính năng này, chúng tôi đã quyết định thêm ngưỡng kích hoạt thứ hai để khắc phục triệt để vấn đề mà BIP34 dự định giải quyết:

Quy tắc 95%: Nếu 950 trong số 1000 khối mới nhất là tầm nhìn 2 trở lên, hãy từ chối tất cả các khối tầm nhìn 1

Một vấn đề đã biết với quy tắc từ chối các phiên bản khối cũ hơn là trừ khi tất cả các công cụ khai thác đã nâng cấp, có thể có một số khối không hợp lệ mỗi ngày (nếu chính xác 95% số công cụ khai thác kích hoạt, thì mỗi khối có 5% tỷ lệ không hợp lệ). Các nút đã được nâng cấp để thực thi các quy tắc ISM sẽ từ chối các khối này, nhưng các nút cũ hơn và máy khách nhẹ không biết về các quy tắc và sẽ chấp nhận chúng. Điều này làm cho mạng phụ thuộc nhiều hơn bình thường vào những người khai thác không tiếp tục khai thác sau các khối không hợp lệ.

[2015] ISM và Khai thác không cần xác minh: Kích hoạt DER nghiêm ngặt BIP66

Vào tháng 9 năm 2014, Pieter Wuille đã tìm thấy sự khác biệt trong cách OpenSSL xử lý các chữ ký được mã hóa DER cho các nền tảng khác nhau. Ví dụ, điều này có thể bị khai thác để tạo một khối vượt qua xác thực trên hệ điều hành Linux nhưng sẽ không thành công trên hệ điều hành Windows—kẻ tấn công tạo ra sự phân chia chuỗi tại điểm đó. Wuille và một số nhà phát triển khác đã phát triển bản vá một cách bí mật và làm việc để kích hoạt nó dưới dạng một nhánh mềm, đảm bảo rằng tất cả các chữ ký đều sử dụng cùng một định dạng. BIP66 được tạo ra cho chính mục đích này, được công bố rộng rãi như một bước hướng tới việc loại bỏ sự phụ thuộc của Bitcoin vào OpenSSL (một mục tiêu thực sự, cuối cùng đã đạt được vào năm 2019). Sau khi BIP66 nhận được đủ sự hỗ trợ từ người dùng và nhà phát triển (nhiều người thậm chí còn không biết lỗ hổng bảo mật tồn tại), nó đã sử dụng cơ chế kích hoạt ISM giống như BIP34, tăng số phiên bản khối lên v3 và yêu cầu ngưỡng 95% cho các khối từ v2 trở xuống số phiên bản sau đó bị từ chối.

Ngưỡng 75% đạt được vào ngày 4 tháng 7 năm 2015 và ngưỡng 95% đạt được ở chiều cao khối 363725. Tất cả các nút đang chạy phần mềm Bitcoin Core v0.10.0 trở lên (hoặc triển khai tương thích) và triển khai các quy tắc mới. Tuy nhiên, ở độ cao khối 363731, một công cụ khai thác không được nâng cấp đã tạo ra một khối không chứa số phiên bản hiện tại, đây không phải là khối hợp lệ theo quy tắc kích hoạt ISM mới. Nhưng những người khai thác khác vẫn tiếp tục sản xuất sau khối không hợp lệ này và cuối cùng đã tạo ra một chuỗi có 6 khối không hợp lệ. Điều này có nghĩa là các nút không được nâng cấp và nhiều khách hàng nhẹ sẽ coi 96 giao dịch trong khối không hợp lệ đầu tiên là các giao dịch đã tích lũy 6 xác nhận khối, ngay cả khi chúng chưa nhận được xác nhận của khối hợp lệ tại thời điểm đó. Cuối cùng, các nhà phát triển không còn lựa chọn nào khác ngoài việc liên hệ với các nhà điều hành nhóm khai thác và yêu cầu họ khởi động lại phần mềm theo cách thủ công và quay lại chuỗi hoạt động. Một sự kiện như vậy lặp lại vào ngày hôm sau, khiến một số giao dịch có ba xác nhận không hợp lệ. May mắn thay, tất cả các giao dịch thông thường trong sáu và ba khối này sau đó đã được đóng gói thành các khối hợp lệ, điều đó có nghĩa là người dùng thông thường không bị thiệt hại.

Khối không hợp lệ ban đầu ở độ cao 363731 là một trong số khoảng 5% khối được ước tính xảy ra mỗi ngày trở nên không hợp lệ chỉ vì chúng sử dụng số phiên bản cũ. Xác suất khối tiếp theo sẽ được khai thác bởi một công cụ khai thác chưa được nâng cấp cũng là 5%, vì vậy xác suất hai khối liên tiếp là khối bị hủy bỏ số phiên bản là 0,25%. Cho rằng 95% người khai thác đã nâng cấp, xác suất 6 khối liên tiếp là khối có số phiên bản không hợp lệ là 0,000002% - nhưng thủ phạm vẫn chưa phải là sự xui xẻo tột độ. Điều không được xem xét là những người khai thác có thể thực hiện "khai thác mà không cần xác minh", nghĩa là sau khi những người khai thác nhận được một khối mới, họ sẽ tiếp tục sản xuất mà không cần xác minh, điều này có thể cải thiện một chút hiệu quả. Mặc dù về mặt lý thuyết, phần mềm khai thác không cần xác minh có thể dễ dàng xử lý các số phiên bản khối không hợp lệ, nhưng tính năng này vẫn chưa được triển khai trong phần mềm được sử dụng bởi những người khai thác đã khai thác năm khối đó vào thời điểm đó. Cuối cùng, đủ thợ đào đã nâng cấp phần mềm khai thác ít bằng chứng hơn hoặc nâng cấp các nút của họ và sự phân tách chuỗi ngẫu nhiên liên quan đến kích hoạt BIP66 đã biến mất.

Để đối phó với những vấn đề này đã dẫn đến đợt phân tách vào tháng 7 năm 2015, các nhà phát triển đã nỗ lực gấp đôi để giảm nhu cầu khai thác không cần xác minh, với các kết quả như chuyển tiếp các khối nén BIP152 và phần mềm FIBER. Các nhà phát triển cũng bắt đầu nghĩ đến một cơ chế kích hoạt tốt hơn, đó là giao thức BIP9 sẽ được đề cập sau.

[2015] ISM cuối cùng: BIP65OP_CHECKLOCKTIMEEVERIFY đã kích hoạt

Trước soft fork DER nghiêm ngặt BIP66, một người nào đó đã đề xuất sử dụng soft fork để thêm opcode mới OP_CHECKLOCKTIMEVERIFY (CLTV) vào Bitcoin, nhưng nó đã bị hoãn lại do sửa chữa lỗ hổng OpenSSL. Điều này cho thấy một điểm yếu khác của cơ chế ISM khi sử dụng số phiên bản gia tăng - nếu một công cụ khai thác báo hiệu hỗ trợ cho đề xuất mới nhất (tầm nhìn n), thì nó hoàn toàn hỗ trợ tất cả các đề xuất trước đó (ví dụ: tầm nhìn n-1). Điều này hạn chế khả năng phối hợp nhiều nâng cấp cùng lúc bằng ISM.

Tuy nhiên, bất chấp một số vấn đề với việc kích hoạt BIP 66, ISM một lần nữa được sử dụng trong quá trình kích hoạt BIP65 bị trì hoãn. Lần này không còn vấn đề gì nữa.

[2016] Bit phiên bản BIP9: Kích hoạt thời gian khóa tương đối BIP68/112/113

BIP9 đề xuất một cơ chế kích hoạt mới để giải quyết một số vấn đề của ISM:

• Xử phạt người khai thác một cách không cần thiết: Việc kích hoạt ISM sẽ làm tăng số phiên bản của khối và một khối được tạo bởi người khai thác không tăng số phiên bản sẽ bị coi là không hợp lệ, ngay cả khi khối đó không vi phạm các quy tắc khác của ngã ba mềm. Ví dụ: trong lần chia tách chuỗi vào ngày 4 tháng 7 năm 2015, tất cả các giao dịch đều tuân theo quy tắc của soft fork - lý do duy nhất khiến những người khai thác này mất 500.000 đô la là do việc nâng cấp yêu cầu tiêu đề khối phải chứa số 3 và không nâng cấp. Người khai thác đã sử dụng 2 .

• Khó song song hóa: với ISM, người ta phải đợi một ngã ba kết thúc trước khi một ngã ba khác có thể bắt đầu thu thập tín hiệu, ngay cả khi nhà phát triển thấy cần thiết.

• Không cho phép thất bại: ISM không đặt thời gian hết hạn. Khi phần mềm nút chờ tín hiệu kích hoạt được giải phóng, các nút chạy phần mềm mới sẽ theo dõi tín hiệu cho đến khi quá trình kích hoạt hoàn tất. Không có cách nào để chắc chắn rằng mọi người không cần soft fork này cả.

• Thời gian kích hoạt không thể đoán trước: Không thể biết trước thời gian kích hoạt chính xác, điều đó có nghĩa là các nhà phát triển giao thức, quản trị viên hệ thống thương gia và nhà điều hành nhóm khai thác khó có thể đưa nó vào sử dụng ngay sau khi kích hoạt, ngay cả khi có trường hợp khẩn cấp cần nhanh chóng. câu hỏi phản hồi.

Các bit phiên bản BIP9 cố gắng giải quyết những vấn đề này. Nó sử dụng trường thị giác bên trong tiêu đề khối dưới dạng trường bit. Dữ liệu trong trường này chỉ được sử dụng để báo hiệu - nó sẽ không được sử dụng làm cơ sở cho các khối không hợp lệ - và có thể được đặt song song. Phép đo được thực hiện sau mỗi khối 2016 để giảm thiểu khả năng một phần nhỏ sức mạnh băm sẽ đủ may mắn để vượt qua mức hỗ trợ 95%. Cuối cùng, khi đạt đến ngưỡng báo hiệu 95%, sẽ có thêm một "thời gian khóa" khối 2016 (khoảng hai tuần) trước khi kích hoạt, để tất cả các bên chuẩn bị cho việc nâng cấp. Nếu không đạt đến ngưỡng kích hoạt trước thời gian hết hạn, thì toàn bộ lần thử ngã ba mềm sẽ kết thúc và mã không sử dụng có thể bị xóa trong bản phát hành phần mềm sau này.

Phương pháp kích hoạt này lần đầu tiên được sử dụng trong ngã ba mềm của số thứ tự được thực thi đồng thuận BIP68, BIP112OP_CHECKSEQUENCEVERIFY và nLockTime được xác định trong BIP113. Đợt fork nhanh chóng bước vào giai đoạn khóa và sau đó tự động bước vào giai đoạn kích hoạt.

[2016-7] BIP9, BIP148 và BIP91: Kích hoạt nhân chứng tách biệt BIP141/143

Bản ngã ba mềm Segregated Witness đã được phát hành với các tham số kích hoạt BIP9. Một số thợ mỏ đã nhanh chóng bày tỏ sự ủng hộ của họ, nhưng mức hỗ trợ thấp hơn nhiều so với ngưỡng 95%. Một số người dùng Bitcoin cảm thấy rằng những người khai thác đã trì hoãn một cách vô lý một tính năng mới hữu ích, vì vậy một kích hoạt tự nguyện đã được phát triển, được gọi là BIP148. Hình thức cuối cùng của BIP148 chỉ định rằng, bắt đầu từ một ngày nhất định, tất cả các khối không hỗ trợ segwit đều bị từ chối,

Sau khi xuất hiện phần mềm triển khai BIP148, có ba loại nút trong mạng - nút không nâng cấp, nút BIP9/141 và nút BIP148/141 - và khả năng rơi vào lỗi đồng thuận thậm chí còn lớn hơn. Nếu các công cụ khai thác không hỗ trợ segwit và phần lớn người dùng tiếp tục coi các khối này là hợp lệ, thì người dùng BIP148 có thể nhận được bitcoin mà những người dùng khác coi là không hợp lệ. Hơn nữa, nếu phần lớn người dùng hỗ trợ BIP148, nhưng những người khai thác tiếp tục tạo ra nhiều khối được BIP148 coi là không hợp lệ, thì những người dùng không triển khai BIP148 sẽ chấp nhận bitcoin mà người dùng BIP148 coi là không hợp lệ. Việc nâng cấp chỉ an toàn nếu người dùng tuân theo các quy tắc giống nhau và hầu hết sức mạnh tính toán đều hỗ trợ các quy tắc BIP148.

Một cách để giảm thiểu rủi ro là cung cấp đủ thời gian để người dùng nâng cấp lên các nút buộc kích hoạt segwit, nhưng BIP148 không thể làm điều này vì mục tiêu của nó là kích hoạt quy trình BIP9 hiện có, nghĩa là buộc các thợ mỏ phải báo hiệu hỗ trợ cho BIP9 từ rất lâu trước đó. ngày hết hạn của nó. Là một giải pháp thay thế có khả năng không phổ biến cho BIP148, BIP149 đề xuất cung cấp cho người dùng thêm một năm để nâng cấp. BIP149 chưa bao giờ nhận được nhiều sự ủng hộ của công chúng, nhưng đây là đề xuất đầu tiên sử dụng BIP8, điều này đã gây ra nhiều cuộc thảo luận hơn trong những năm tới.

Khi BIP148 bắt đầu nhận được sự ủng hộ đáng kể của công chúng, nhiều thợ mỏ, sàn giao dịch và nhân vật trong ngành đã bày tỏ sự ủng hộ đối với đề xuất hai bước để kích hoạt Segregated Witness trong khi vẫn duy trì sự đồng thuận với các nút hỗ trợ BIP148. Bước đầu tiên được viết bằng BIP91, giúp cải thiện các quy tắc của BIP9. Người khai thác có thể sử dụng trường bit BIP9 để cho biết liệu họ có thực thi quy tắc tạm thời hay không: từ chối tất cả các khối không báo hiệu hỗ trợ cho BIP141/143 Segregated Witness. Không giống như BIP9, ngưỡng của BIP91 đã giảm từ 95% xuống 80%, trong khi thời lượng theo dõi và khóa của nó đã giảm từ 2016 khối xuống còn 336 khối.

BIP91 bị khóa và kích hoạt. Sau đó, BIP141/143 bị khóa và kích hoạt. Khi chúng bị khóa, các biện pháp hỗ trợ bắt buộc của BIP148 sẽ hết hiệu lực.

Giai đoạn thứ hai của đề xuất này từ các công ty khai thác, sàn giao dịch và các nhân vật trong ngành yêu cầu một đợt hard fork, đề xuất này đã bị những người ký tên vào đề xuất rút lại sau khi một số lượng lớn người dùng cá nhân và doanh nghiệp phản đối quyết liệt.

Cho đến ngày nay, mọi người vẫn đang tranh luận xem những sự kiện này và những sự kiện khác xảy ra cùng thời điểm đóng vai trò như thế nào trong việc kích hoạt Segregated Witness.

kích hoạt khẩn cấp

Đã hơn một lần, các lỗi nghiêm trọng được tìm thấy trong mã đồng thuận và các nhà phát triển đã phát hành các bản vá mà không cần trải qua quá trình kích hoạt. Làm như vậy có thể dẫn đến lỗi đồng thuận, nhưng cũng ngay lập tức loại bỏ lỗ hổng cho các nút được nâng cấp. Các sự kiện quan trọng bao gồm:

• Sử dụng chuỗi để thay thế chiều cao (tháng 7 năm 2010): Bitcoin ban đầu coi chuỗi có nhiều khối nhất ("chuỗi dài nhất") là chuỗi hợp lệ. Nếu mọi khối có cùng độ khó, thì chuỗi dài nhất như vậy cũng sẽ là chuỗi tích lũy được nhiều bằng chứng công việc nhất. Nhưng các khối khác nhau có những khó khăn khác nhau, vì vậy soft fork chainwork đã được phát hành trong Bitcoin 0.3.3 và chuỗi có bằng chứng công việc tích lũy nhiều nhất được coi là chuỗi hợp lệ.

• Loại bỏ các lỗi bỏ qua tập lệnh (tháng 7 năm 2010): Bitcoin ban đầu kết hợp tập lệnh sử dụng UTXO (scriptSig) và tập lệnh bảo vệ UTXO (scriptPubKey) và đánh giá chúng đồng thời. Thiết kế này cho phép một người chấm dứt tập lệnh trước khi cơ chế khóa được đánh giá, thoát với trạng thái thành công, chẳng hạn như trước khi chạy OP_CHECKSIG để kiểm tra chữ ký. Lỗi này ban đầu được báo cáo là scriptSig sử dụng OP_TRUE OP_RETURN có thể tiêu bitcoin của bất kỳ ai. Lỗi này lần đầu tiên được sửa trong Bitcoin 0.3.6 bằng cách làm cho OP_RETURN luôn bị lỗi và gán số cho các màn hình khác trong tập lệnh. Mặc dù tất cả những thay đổi này đều là các nhánh mềm, nhưng các thay đổi đối với cùng một mã (sau này đã loại bỏ một số hạn chế nhất định) cũng dẫn đến các thay đổi kiểu hard fork. Ngay cả với một thay đổi lớn như vậy, vấn đề cơ bản là scriptSig có thể can thiệp vào hoạt động của scriptPubKeys vẫn tồn tại, do đó, soft fork thứ hai đã được triển khai trong Bitcoin 0.3.8, cho phép cả hai thực thi độc lập.

• Đã sửa lỗi tràn (tháng 8 năm 2010): Ai đó đã tạo một giao dịch để chi 0,5 btc và tạo hai đầu ra trị giá 92.233.720.368,54277039 BTC. Bitcoin yêu cầu giá trị đầu ra không được lớn hơn giá trị đầu vào, nhưng phương pháp phát hiện là thêm giá trị đầu ra vào một số nguyên 64 bit có thể biểu thị tới 9.223.372.036.854.776 Satoshi (khoảng 92 triệu btc). Điều này có nghĩa là giao dịch dường như chỉ có tổng chi phí là -0,1 btc. Điều này cũng bỏ qua một quy tắc khác cấm các đầu ra âm riêng lẻ, nhưng không cấm tổng các giá trị âm - vì nó giả định rằng tổng của bất kỳ giá trị dương nào sẽ vẫn dương. Điều này cho phép ai đó tạo ra 184 tỷ btc và thủ thuật này có thể được lặp lại mà không tốn bất kỳ chi phí nào, tạo ra vô số bitcoin. Trong vòng vài giờ, Bitcoin 0.3.10 đã phát hành một bản vá soft fork giới hạn sản lượng ở mức 21 triệu btc. Nó cũng yêu cầu từ bỏ các chuỗi có quá nhiều giao dịch — một lỗi đồng thuận có chủ ý, nhưng cần thiết để Bitcoin vẫn có ý nghĩa.

• Khắc phục tạm thời sự cố khóa BDB (tháng 3 năm 2013): Vào đầu năm 2012, các nhà phát triển Bitcoin nhận ra rằng nếu có quá nhiều thay đổi được thực hiện đối với cơ sở dữ liệu UTXO (trạng thái chuỗi) cùng một lúc, một trong những giới hạn dung lượng mặc định cho dữ liệu trạng thái chuỗi có thể là vượt quá. Bởi vì các khối Bitcoin tương đối nhỏ vào thời điểm đó, điều này chỉ được quan sát thấy khi chuỗi khối được tổ chức lại, yêu cầu các giao dịch từ nhiều khối phải được xử lý đồng thời. Một giải pháp đơn giản đã được thực hiện vào thời điểm đó: trong quá trình tổ chức lại, chỉ xử lý các giao dịch từ một khối tại một thời điểm. Sau đó, một số người bắt đầu yêu cầu những người khai thác tăng kích thước khối mặc định tùy chọn từ 250 KB. Vào ngày 12 tháng 3 năm 2013, một công cụ khai thác đã tạo ra một khối ~1 MB chứa hơn 1.700 giao dịch—khối Bitcoin lớn nhất cho đến nay—vượt quá dung lượng của cơ sở dữ liệu trên nhiều nút, khiến họ coi khối đó là không hợp lệ mặc dù nó hoàn toàn tuân thủ Quy tắc đồng thuận rõ ràng của Bitcoin. Để làm cho nước trở nên đục hơn, một phiên bản mới của Bitcoin Core đã được phát hành, sử dụng một công cụ cơ sở dữ liệu khác mà không có giới hạn này, vì vậy nó có thể nhận khối lớn hơn này một cách an toàn - vì vậy các phiên bản nút khác nhau đã xảy ra lỗi đồng thuận. Sau khi phân tích nhanh tình hình, các nhà phát triển khuyến khích người dùng tạm thời hạ cấp xuống phiên bản cũ hơn (sẽ từ chối phiên bản có khối lớn này), sau đó cập nhật lên phiên bản khẩn cấp tạm thời giảm giới hạn kích thước khối xuống 500 KB với một soft fork , để cho phép mọi người dùng có thời gian nâng cấp lên công cụ cơ sở dữ liệu mới và việc hạ cấp tạm thời này sẽ tự động hết hạn sau một vài tháng.

kích hoạt trong tương lai

Sau nhiều tháng gặp sự cố khi kích hoạt Segwit, một số người bắt đầu nghĩ về BIP8. Những người ủng hộ BIP8 tin rằng nó có thể giải quyết một số vấn đề của BIP9:

• Cho phép kích hoạt bắt buộc: BIP8 là sự tổng quát hóa của BIP148, những người khai thác có thể tự nguyện báo hiệu sự ủng hộ của họ trong khoảng thời gian chờ kích hoạt, nhưng nó cũng đặt ra một khoảng thời gian tối hậu thư trong đó những người khai thác phải báo hiệu sự ủng hộ của họ, nếu không, các khối được tạo ra có thể trở nên không hợp lệ. Sau đó, mọi người đã thiết kế một tham số LockinOnTimeout (LOT) để kích hoạt hành động này: các nút sử dụng LOT=true sẽ yêu cầu người khai thác gửi tín hiệu trong khoảng thời gian cuối cùng khi sắp hết thời gian kích hoạt; các nút sử dụng LOT=false sẽ không yêu cầu this , nhưng các quy tắc mới sẽ vẫn được áp dụng nếu có đủ khối được báo hiệu.

• Sử dụng độ cao thay vì thời gian: BIP9 bắt đầu và dừng theo dõi các tín hiệu kích hoạt dựa trên mức trung bình của thời gian các công cụ khai thác ghi khối. Do đó, những người khai thác có thể thao túng thời gian này, điều này sẽ cản trở chức năng của LOT=true, vì vậy BIP8 đề xuất sử dụng chiều cao khối thay vì thời gian.

Tính linh hoạt của BIP8 đã khiến nó trở thành một trong nhiều đề xuất kích hoạt ứng cử viên cho soft fork taproot, mặc dù các nhà phê bình cũng chỉ trích một số khía cạnh của nó, chẳng hạn như một số cài đặt nhất định cho phép thợ mỏ từ chối kích hoạt các đề xuất có sự hỗ trợ rộng rãi của cộng đồng, khuyến khích một Nhóm "nắm bắt" cơ chế báo hiệu được sử dụng bởi một nhóm khác, yêu cầu những người khai thác thực hiện những thay đổi không đáng kể đối với các khối được tạo ra, dường như trao quyền cho các nhà phát triển đối với các quy tắc đồng thuận và tăng nguy cơ thất bại đồng thuận. Khi viết bài này, các cuộc thảo luận về phương pháp kích hoạt taproot vẫn đang tiếp diễn.

Các ý tưởng khác đã được thảo luận, bao gồm "kích hoạt soft-fork xác suất (sporks)", "kích hoạt soft-fork nhiều giai đoạn (MSFA)", "kích hoạt giảm ngưỡng (decthresh)", "trả về độ cao hoặc thời gian kích hoạt được mã hóa cứng (ngày gắn cờ)" và "Thời gian tín hiệu ngắn hơn sau khi trễ kích hoạt (dùng thử nhanh)".

mã chính và tài liệu

• BIP9

• BIP8

Tin tức Optech và các phần liên quan của trang web

(nhiều, ít)

Xem thêm

• Độ cao, thời gian và ngưỡng kích hoạt BIP

• Taproot