Trừu tượng

Bài viết này đi sâu vào các phương pháp thực tế để cho phép xác minh ZK trong Bitcoin, bao gồm các chủ đề như mô hình UTXO của Bitcoin, giới hạn kịch bản, Taproot, OP_CAT, BitVM và Bằng chứng trạng thái chuỗi. Nó trình bày một lập luận rõ ràng rằng việc tích hợp ZK vào giao thức Bitcoin là không thể tránh khỏi. Hai con đường tiềm năng được nêu bật: một là giới thiệu lại opcode OP_CAT để hỗ trợ trực tiếp xác minh SNARK trong các tập lệnh Bitcoin – một thay đổi có khả năng phê duyệt cuối cùng cao. Cách tiếp cận thứ hai xoay quanh BitVM, kết hợp các bằng chứng gian lận. Ngoài ra, đề xuất của nhóm ZeroSync về Bằng chứng trạng thái chuỗi nhằm giảm chi phí xác minh dữ liệu lịch sử cho các máy khách nút.

Văn bản chính: Để hiểu rõ Bitcoin, việc xem nó như một hệ thống xã hội sẽ hữu ích. Vào những ngày đầu, người sáng tạo Bitcoin đã định nghĩa phần mềm mà các nút phải chạy, tương tự như việc thiết lập các quy tắc điều hành một xã hội. Sự ổn định của Bitcoin phụ thuộc vào một sự đồng thuận rộng rãi về bản chất cơ bản của nó, dẫn đến những câu hỏi như “Bitcoin ở cốt lõi là gì?” và “Bitcoin nên phát triển thành cái gì?”. Tuy nhiên, việc đạt được sự đồng thuận về những câu hỏi này thường khó khăn, vì ý kiến ​​thay đổi rộng rãi và liên tục.

Điều này quay trở lại nguồn gốc lịch sử của Bitcoin. Khi Satoshi Nakamoto phát hành bản trắng của Bitcoin, ông nói: “Tôi đang làm việc trên một hệ thống thanh toán điện tử hoàn toàn mới. Hệ thống này hoàn toàn là P2P và không cần phải phụ thuộc vào bất kỳ bên thứ ba nào.” Đoạn này đã được đăng trên danh sách gửi email Cypherpunks (một nhóm thảo luận qua email được thành lập vào năm 1992, bao gồm một nhóm mật mã học và người yêu công nghệ quan tâm đến bảo vệ quyền riêng tư và công nghệ mật mã).

Tuy nhiên, Bitcoin giới hạn thông lượng dữ liệu ở cấp độ thiết kế sản phẩm. Số lượng giao dịch mà nó có thể xử lý trên mỗi đơn vị thời gian bị giới hạn. Nếu số lượng giao dịch được xử lý tăng nhanh, người dùng sẽ bắt đầu một cuộc chiến về giá để hoàn thành giao dịch thành công một cách nhanh chóng, nhanh chóng tăng phí xử lý phải trả. Giao dịch đơn lẻ có phí xử lý cao nhất trong mạng Bitcoin xảy ra sau khi phần thưởng khối giảm một nửa vào năm 2024 và phí xử lý cho một giao dịch có mức độ ưu tiên trung bình trên chuỗi đạt 150 đô la. Có thể nói, phí giao dịch đắt đỏ của mạng Bitcoin đã trở thành một vấn đề.

Để giải quyết vấn đề phí giao dịch, mọi người đã đầu tư rất nhiều tài nguyên vào việc phát triển Mạng Lightning. Nhưng theo một bài báo được công bố vào năm 2016, Mạng Lightning chỉ có thể hỗ trợ hàng chục triệu người dùng trong thực tế và không thể thực hiện tầm nhìn của mình về một hệ thống thanh toán toàn cầu. Ngoài vấn đề phí giao dịch quá đắt đỏ, còn có một vấn đề khác, đó làBitcoin chưa bao giờ có thể đạt được tính nặc danh mà nó mơ ước.

Satoshi Nakamoto đã chỉ ra trong một nhóm thảo luận email cypherpunk rằng Bitcoin có chức năng bảo vệ sự riêng tư và người khởi xướng giao dịch có thể hoàn toàn nặc danh. Tuy nhiên, mặc dù người khởi xướng giao dịch không yêu cầu KYC, dữ liệu giao dịch trên chuỗi Bitcoin rò rỉ rất nhiều thông tin, tiết lộ quyền riêng tư của người dùng một cách lớn lao. Mặc dù có một số khách hàng ví có chức năng bảo mật giải quyết các vấn đề trên một mức độ nhất định, nhưng các nhà phát triển của các khách hàng ví này đối mặt với các mối đe dọa với các quy mô khác nhau. Ví dụ, nhà phát triển của ví Samourai CoinJoin đã bị FBI bắt vào tháng 4 năm 2024, và một tuần sau đó, nhà phát triển của ví Wasabi đã tắt thành phần phối hợp CoinJoin của họ. Rõ ràng, những ví được gọi là bảo mật này không hoàn toàn xứng đáng được sự tin tưởng của người dùng.

Tóm lại, nhiều khái niệm về Bitcoin vẫn chưa được thực hiện đến ngày hôm nay và các công nghệ liên quan vẫn đang tiếp tục phát triển. Mặc dù vậy, nhiều người trong cộng đồng Bitcoin tin rằng thiết kế giao thức của Bitcoin nên được giữ nguyên, nhưng cũng có nhiều người, giống như tôi, đam mê việc cải tiến Bitcoin. Vậy, Bitcoin nên phát triển theo hướng nào?

Để đáp ứng các vấn đề trên, có nhiều đề xuất trong cộng đồng Bitcoin, và những đề xuất có kết quả lý thuyết tốt nhất nên liên quan đến ZK và SNARKs. Với ZK và SNARKs, có thể đạt được các tính năng sau:

1. Quyền riêng tư được cải thiện đáng kể: sử dụng cam kết Peterson đồng cấu với số tiền giao dịch và Bằng chứng phạm vi để cải thiện đáng kể quyền riêng tư của người dùng (chẳng hạn như được thực hiện trong chuỗi bên Element của Blockstream); sử dụng chữ ký có thể liên kết (chẳng hạn như Monero) để ẩn dấu vết giao dịch; đạt được các giao dịch thực sự riêng tư (chẳng hạn như Zcash).

2. Nâng cao lưu lượng giao dịch

Nhiều giải pháp kỹ thuật có thể giải quyết các vấn đề hiện tại của Bitcoin, nhưng tại sao những công nghệ này chưa được tích hợp vào giao thức Bitcoin? Câu trả lời nằm ở độ khó của việc sửa đổi giao thức. Khác với Ethereum, Bitcoin không có một tổ chức tập trung như Ethereum Foundation. Bất kỳ thay đổi giao thức nào đều yêu cầu một mức độ đồng thuận cộng đồng cao, liên quan đến đàm phán và cân đối lợi ích một cách kỹ lưỡng. Kết quả là, trong khi Ethereum thường xuyên cập nhật các opcode EVM của mình, giao thức Bitcoin đã ít thấy những thay đổi kể từ khi ra đời.

Một cách nào đó, khó khăn trong việc thay đổi giao thức này là có lợi. Nếu việc thay đổi dễ dàng triển khai, những sửa đổi hay tấn công độc hại sẽ xảy ra nhiều hơn. Điều này đặt ra câu hỏi: Làm thế nào để cải thiện hiệu suất của Bitcoin mà không làm thay đổi giao thức?

Để trả lời câu hỏi này, chúng ta cần xem xét lại một số khái niệm cơ bản về Bitcoin. Khi bạn chuyển Bitcoin cho người khác, bạn tạo ra một giao dịch và phát sóng nó đến mạng Bitcoin. Dữ liệu đầu ra của giao dịch xác định số lượng BTC đang được chuyển. Người nhận sau đó có thể tạo ra một giao dịch mới để tiêu thụ số BTC nhận được, tạo ra dữ liệu đầu ra mới trong quá trình.

Lưu ý quan trọng là Bitcoin không có trạng thái toàn cầu như Ethereum, đặc biệt là thiếu trạng thái tài khoản; nó chỉ có dữ liệu đầu ra giao dịch. Mỗi đầu ra giao dịch có hai trạng thái: hoặc đã được chi bởi người nhận hoặc vẫn chưa được chi. Đầu ra giao dịch chưa được chi (UTXOs) là những gì chúng ta quen thuộc. Ngoài số lượng BTC liên quan, mỗi đầu ra giao dịch cũng có một kịch bản đính kèm được viết bằng Bitcoin Script. Bất kỳ ai có thể cung cấp chứng minh chính xác (Chứng kiến) cho kịch bản này có thể chi tiêu UTXO.

Bitcoin Script là một ngôn ngữ lập trình dựa trên ngăn xếp với một loạt các opcode. Các chương trình được gắn kết với UTXOs thường bao gồm nhiều opcode, thực hiện tính toán dựa trên ngăn xếp và trả kết quả về nó. Nhiều Bitcoin script thông thường đã tồn tại từ khi Bitcoin ra đời. Ví dụ, script thông thường nhất bao gồm một khóa công khai và một opcode kiểm tra chữ ký số. Opcode này yêu cầu khi tiêu thụ hoặc mở khóa một UTXO, người dùng phải cung cấp một chữ ký số tương ứng với khóa công khai.

Đọc tiếp: [Tiếp cận BTC: Kiến thức cơ bản để hiểu BitVM (1)]

Khả năng của Bitcoin Script

Những gì Kịch bản Bitcoin có thể làm được:

• Sắp xếp ngăn xếp và thực hiện kiểm tra tính bằng nhau (để xác minh các điều kiện cụ thể và đảm bảo an toàn giao dịch và tính hợp lệ).
• Thực hiện các hoạt động điều kiện tương tự như câu lệnh if-else.
• Thực hiện các phép toán hạn chế trên số 32-bit, như phép cộng và phép trừ.
• Mã hóa dữ liệu và xác minh chữ ký ECDSA và Schnorr.

Những gì Bitcoin Script Không Thể Thực Hiện Được:

• Không có vòng lặp, nhảy hoặc đệ quy; nó không đủ mạnh để tính toán Turing, với khả năng lập trình rất hạn chế.
• Không thể thực hiện các phép toán bit.
• Thiếu các opcode cho phép nhân và chia.
• Không thể nối các phần tử trên ngăn xếp.
• Có khả năng đọc và xác minh dữ liệu giao dịch trên chuỗi rất hạn chế. Bitcoin Script không thể trực tiếp truy cập số tiền của mỗi giao dịch và không thể truyền trạng thái (UTXO chỉ sử dụng một lần và mỗi lần chuyển giao dịch đốt cháy giao dịch cũ và tạo ra giao dịch mới).

Trong các phiên bản đầu của Bitcoin, một số chức năng 'không thể' được đề cập ở trên đã có thể thực hiện, nhưng một số mã opcode đã bị vô hiệu hóa sau đó bởi Satoshi Nakamoto do lỗ hổng bảo mật. Ví dụ, mã opcode OP_CAT, có thể kết hợp hai phần tử trong ngăn xếp, đã được sử dụng để tấn công từ xa các nút Bitcoin và gây ra sự cố. Satoshi đã vô hiệu hóa OP_CAT và các mã opcode khác vì lý do bảo mật.

Vậy, liệu Bitcoin Script có thể xác minh SNARKs không? Về lý thuyết, ngay cả khi Bitcoin Script không hoàn toàn Turing, các hoạt động cơ bản của nó vẫn đủ để xác minh bất kỳ phép tính nào. Tuy nhiên, trong thực tế, việc xác minh SNARK không khả thi vì kích thước chương trình cần thiết cho các bước xác minh vượt quá giới hạn khối tối đa của Bitcoin là 4MB. Mặc dù chúng ta có thể cố gắng thực hiện các phép tính số học trong các trường hữu hạn lớn, nhưng chi phí sẽ quá cao. Ví dụ, trong BitVM, việc nhân hai số nguyên 254 bit dẫn đến kích thước script Bitcoin gần 8KB. Hơn nữa, mà không có OP_CAT, chi phí của việc xác minh chứng minh Merkle cũng cao, vì điều này yêu cầu các hoạt động tương tự như vòng lặp.

Vậy tại sao không chỉ cần sửa đổi giao thức Bitcoin để thêm các mã opcode mạnh mẽ hơn? Như đã đề cập trước đó, việc đạt được sự đồng thuận đa số về các quy tắc giao thức mới rất khó khăn. Bitcoin thiếu một người quyết định tập trung, và mọi đề xuất cải tiến Bitcoin Script đều đối mặt với sự phản đối đáng kể từ các bên liên quan có quan điểm khác nhau. Không có cách hiệu quả nào để đo lường sự đồng thuận trong cộng đồng trên mạng Bitcoin, và buộc phải cập nhật mà không có sự đồng thuận có thể dẫn đến chia rẽ chuỗi. Tất nhiên, Bitcoin không hoàn toàn bất biến. Các cập nhật gần đây nhất là SegWit vào năm 2017 và Taproot vào năm 2021.

Bản nâng cấp Taproot, đã thay đổi nhiều quy tắc, mất ba năm rưỡi để chuyển từ việc phát hành lý thuyết sang việc kích hoạt thực tế. Yếu tố chính để kích hoạt Taproot là nó không thay đổi các giả định bảo mật hiện có và rõ ràng cải thiện giao thức Bitcoin. Ví dụ, nó cho phép sử dụng chữ ký Schnorr thay vì ECDSA. Cả hai đều dựa trên giả định logarit rời rạc và sử dụng cùng một đường cong elip, nhưng cái nào hiệu quả hơn và yêu cầu tính toán ít hơn.

Ngoài ra, các cải tiến của Taproot đối với Bitcoin có thể được phân loại thành ba khía cạnh sau đây:

Đầu tiên, Taproot giảm chi phí xác minh của các kịch bản có nhiều nhánh điều kiện, cho phép Bitcoin hỗ trợ các chương trình phức tạp hơn.

Thứ hai, Taproot giảm lượng dữ liệu script cần phải tiết lộ trên chuỗi, và bạn có thể lắp ráp nhiều chương trình script vào một cây Merkle, với mỗi script nằm trên một lá khác nhau. Nếu bạn muốn kích hoạt một chương trình script cụ thể, bạn chỉ cần tiết lộ lá nơi nó đặt và chứng minh Merkle;

Thứ ba, Taproot cũng thêm các thiết kế cơ chế khác.

Xem xét tiền lệ của Bitcoin với Taproot để tích hợp các tính năng nâng cao hơn, người ta có thể tự hỏi tại sao một opcode chuyên dụng để xác minh SNARK chưa được giới thiệu. Sự khác biệt chính nằm ở sự phức tạp và đồng thuận cần thiết cho OP_SNARK. Không giống như Taproot, có thiết kế rõ ràng, đơn giản nhận được sự ủng hộ rộng rãi, các đề xuất OP_SNARK rất khác nhau, khiến việc tập hợp cộng đồng xung quanh một cách tiếp cận duy nhất trở nên khó khăn. Nếu được triển khai, mọi nút Bitcoin sẽ cần hỗ trợ phương pháp xác minh SNARK cụ thể này, điều này sẽ làm tăng đáng kể nhu cầu kỹ thuật. Hơn nữa, sự phức tạp vốn có của OP_SNARK là một trở ngại lớn — Taproot đã thêm khoảng 1.600 dòng mã, có thể quản lý theo tiêu chuẩn cộng đồng, trong khi OP_SNARK sẽ đòi hỏi mã hóa phức tạp hơn nhiều. Hơn nữa, việc xác định ai sẽ đánh giá việc kích hoạt OP_SNARK và đạt được sự đồng thuận khi ít người nắm bắt đầy đủ sự phức tạp của nó làm tăng thêm các lớp khó khăn. Với những thách thức này, việc nâng cấp OP_SNARK khó có thể thành hiện thực trong tương lai gần.

Tuy nhiên, cũng có những cách khác để xác minh SNARKs trong Bitcoin Script. Chúng ta có thể làm cho các Bitcoin script linh hoạt hơn bằng cách thêm các opcode đơn giản hơn, cho phép mọi người triển khai các chương trình kiểm tra viên SNARK trong các script. Nhưng thực tế, việc viết một chương trình xác minh SNARK trong ngôn ngữ Bitcoin script rất khó. Do đó, nhóm nghiên cứu của Blockstream đang phát triển Simplicity, một ngôn ngữ lập trình được thiết kế để thay thế Bitcoin Script. Simplicity được thiết kế đặc biệt cho các hệ thống đồng thuận blockchain và không phải là Turing-complete cố ý, làm cho việc phân tích tĩnh và xác minh hình thức dễ dàng.

Hãy chuyển sự chú ý của chúng ta vào một đề xuất có vẻ đơn giản nhưng lại có tác động lớn có thể cải thiện đáng kể khả năng viết kịch bản của Bitcoin: việc kích hoạt lại opcode OP_CAT. OP_CAT ban đầu được bao gồm trong mã nguồn sớm của Bitcoin nhưng sau đó đã bị vô hiệu hóa bởi Satoshi Nakamoto do khả năng tiềm ẩn của nó cho phép tấn công DoS trong điều kiện cụ thể. Tuy nhiên, hiện nay có sự quan tâm ngày càng tăng trong cộng đồng Bitcoin để đưa nó trở lại.

Chức năng của OP_CAT rất đơn giản - nó lấy hai phần tử trên cùng từ ngăn xếp, nối chúng lại và đẩy kết quả trở lại ngăn xếp. Mặc dù điều này có thể xuất hiện cơ bản, nhưng nó có tiềm năng mở khóa những cải tiến đáng kể trong ngôn ngữ lập trình của Bitcoin. Ví dụ, các script Bitcoin hiện tại không thể truy cập vào một số dữ liệu giao dịch on-chain như số lượng liên quan, nhưng với OP_CAT, khả năng này có thể được giới thiệu. Ngoài ra, OP_CAT cũng có thể giúp xác minh các chứng minh Merkle.

Về bản chất, OP_CAT là một nâng cấp mã hóa cấp thấp có thể dẫn đến một loạt các chức năng mới. Nhiều người đã chỉ ra rằng OP_CAT có thể rất quan trọng trong việc đạt được các mục tiêu khác nhau. Một câu hỏi quan trọng là liệu OP_CAT có thể hỗ trợ trong việc xác minh SNARK trong các tập lệnh hay không. Câu trả lời là có. Khi xác minh chứng minh Merkle là một bước tiến về việc xác minh FRI-based SNARKs, OP_CAT sẽ là một bổ sung có giá trị. Trong quá khứ, các tập lệnh được thiết kế để xác minh SNARK có thể đã quá lớn để vừa với giới hạn kích thước khối của Bitcoin, nhưng OP_CAT có thể giúp tối ưu hóa các tập lệnh này, làm cho chúng trở nên gọn gàng hơn.

OP_CAT đã được thảo luận trong nhiều năm, với sự nhận thức ngày càng tăng về vai trò tiềm năng của nó trong việc phân tích giao dịch. Một trong những ưu điểm lớn của nó so với các đề xuất khác là nó từng là một phần không thể thiếu của Bitcoin Script, điều này có thể làm cho việc đạt được sự đồng thuận của cộng đồng dễ dàng hơn. Tuy nhiên, nhược điểm là việc kích hoạt OP_CAT có thể ảnh hưởng tiêu cực đến lợi nhuận MEV (Giá trị có thể khai thác bởi người đào) của một số người, điều này đã dẫn đến cuộc tranh luận tiếp tục trong cộng đồng về việc kích hoạt lại nó.

Tóm lại, Bitcoin có thể tiến một bước để cho phép xác minh SNARK trong các kịch bản bằng cách tái giới thiệu các opcode đơn giản như OP_CAT. Ngoài ra, đáng kể là một đề xuất gần đây gọi là “Great Script Restoration” (Tái thiết kịch bản tuyệt vời), tái giới thiệu một opcode nhân và cho phép tất cả các phép toán số học được thực hiện với độ chính xác tùy ý.

Ngoài ra, khi đánh giá tác động của OP_CAT đối với mạng Bitcoin, quan trọng phải xem xét ảnh hưởng của nó đến các nhà điều hành nút Bitcoin. Để đảm bảo Bitcoin vẫn chống lại sự kiểm duyệt và phi tập trung, cộng đồng cố gắng có nhiều người nhất chạy nút để xác minh giao dịch. Nếu Bitcoin triển khai xác minh SNARK, nó sẽ không làm tăng đáng kể chi phí vận hành một nút, điều đó không ảnh hưởng đến an ninh hoặc khả năng chống kiểm duyệt của Bitcoin.

Hiện tại, một khối Bitcoin có thể chứa đến 4MB dữ liệu, với các khối mới được đào khoảng mỗi 10 phút. Hầu hết các khối đều chứa các kịch bản Bitcoin và dữ liệu Witness (tương tự như chữ ký số). Trung bình, mỗi khối có thể chứa được từ 7.000 đến 10.000 xác minh chữ ký, với tối đa khoảng 80.000 xác minh trên mỗi khối. Để có bối cảnh, CPU Intel của tôi năm 2020 cần khoảng 3,2 giây để xác minh một khối Bitcoin. Tự nhiên, tốc độ xác minh khối bị ảnh hưởng bởi các yếu tố vượt quá thời gian xác minh chữ ký.

Ngoài ra, nếu giao dịch Bitcoin cuối cùng hỗ trợ chứng minh không cần dẫn (ZK), bất kỳ tăng thời gian tạo giao dịch nào cũng có thể không phải là mối quan tâm lớn. Ví cứng, được sử dụng để lưu trữ tài sản lâu dài, thường có màn hình và thiết kế nhỏ gọn tập trung vào việc lưu trữ và tạo chữ ký. Những chiếc ví này thường có CPU tương đối ít công suất, như bộ xử lý hai lõi 240MHz, nhưng chúng vẫn xử lý giao dịch Bitcoin một cách hiệu quả.

Tôi đã tiến hành một cuộc khảo sát nhỏ hỏi người dùng về độ trễ tối đa mà họ chấp nhận để một thiết bị ký tạo ra một bằng chứng, và rất nhiều người đồng ý chờ đợi lâu hơn, đặc biệt nếu có lợi ích đáng kể. Vì vậy, nếu chúng ta giới thiệu ZK vào giao dịch Bitcoin, không có vẻ gì là khó khăn.Ta đã dành rất nhiều thời gian để thảo luận về các thay đổi tiềm năng cho thiết kế cơ bản của Bitcoin, nhưng có rất nhiều ứng dụng có thể được phát triển mà không cần thay đổi Bitcoin chính mình. Một ứng dụng đáng kể như vậy là Chứng minh Trạng thái Chuỗi, liên quan đến BitVM. Phương pháp này sử dụng bằng chứng không cần biết để xác minh tính chính xác của các hash khối.

Công nghệ này ảnh hưởng như thế nào đối với Bitcoin? Đầu tiên, Bằng chứng Trạng thái Chuỗi có thể giảm thiểu đáng kể công việc liên quan đến đồng bộ hóa và xác minh dữ liệu lịch sử của Bitcoin, từ đó giảm chi phí vận hành một nút. Hiện tại, đồng bộ hóa và xác minh dữ liệu từ khối khởi đầu đến khối mới nhất mất khoảng 5 giờ 30 phút trên thiết bị cao cấp, và vài ngày trên thiết bị cấp Raspberry Pi. Bằng chứng Trạng thái Chuỗi có thể rút ngắn quá trình này một cách đáng kể.

Thứ hai, Chain State Proofs đóng vai trò quan trọng trong việc thúc đẩy BitVM. Nhóm ZeroSync đã nghiên cứu kỹ lưỡng về Chain State Proofs và phát triển một phiên bản được rút gọn gọi là “header chain Proofs”. Phương pháp này sử dụng zero-knowledge proofs để xác minh Bitcoin block headers, tạo ra một “header chain” bao gồm tất cả 850,000 block headers trong lịch sử của Bitcoin. Mỗi block header được hash để tạo ra một proof có 80 byte. Phương pháp này yêu cầu tính toán double SHA-256 cho mỗi header để xác minh proof of work liên quan. ZeroSync sử dụng STARKs để tạo ra các proof cho header chain này, mất khoảng 4,000 đô la để sản xuất, trong khi quá trình xác minh chỉ mất khoảng 3 giây trên trình duyệt của tôi.

Tuy nhiên, vì chứng minh chuỗi tiêu đề không xác minh các giao dịch trong các khối, chúng chỉ có thể giả định rằng blockchain với nhiều bằng chứng công việc (PoW) nhất là hợp lệ và dựa vào các máy khách Bitcoin để đồng bộ các khối mới nhất từ chuỗi này. Trong thiết lập này, một kẻ tấn công có thể lý thuyết tạo ra các khối có giao dịch không hợp lệ, thêm nhiều khối sau đó và tạo ra một chứng minh chuỗi tiêu đề để đánh lừa các máy khách đồng bộ dữ liệu lịch sử. Tuy nhiên, chi phí cho một cuộc tấn công như vậy sẽ quá cao và nó có thể bị phát hiện bởi các máy khách Bitcoin full node hiện có.

Tuy nhiên, mặc dù khả năng thành công của cuộc tấn công như vậy là thấp, nếu nó có thể cho phép kẻ tấn công đánh cắp một lượng lớn BTC, bằng chứng chuỗi tiêu đề sẽ không được coi là một giải pháp an toàn hoàn toàn. Để xác minh trạng thái đầy đủ của chuỗi, chúng ta cần đảm bảo rằng tất cả nội dung khối Bitcoin là hợp lệ, bao gồm xác minh chữ ký ECDSA và Schnorr dựa trên đường cong elliptic secp256k1. Các khối lịch sử của Bitcoin chứa khoảng 30 triệu chữ ký mỗi tháng, tổng cộng khoảng 2,5 tỷ chữ ký trong lịch sử, cùng với nhiều tính toán SHA-256. Kết quả là, mạng lưới Bitcoin tạo ra khoảng 7GB dữ liệu khối mỗi tháng, với dữ liệu lịch sử vượt quá 650GB — và trong thực tế, con số này có thể cao gấp 2 đến 3 lần.

Bây giờ, chúng ta hãy nhìn vào BitVM. BitVM cho phép Bitcoin xác minh bất kỳ tác vụ tính toán nào, cung cấp một cách tối ưu để thực hiện xác minh SNARK mà không cần sửa đổi giao thức. BitVM khắc phục giới hạn kích thước tập lệnh của Bitcoin bằng hai phương pháp. Đầu tiên, nó tận dụng cấu trúc tập lệnh Taproot MerkleTree. Thứ hai, nó sử dụng sơ đồ lưu trữ KV có thể được truy cập trên các tập lệnh riêng lẻ, tạo điều kiện kết nối với một số lượng lớn các chương trình tập lệnh. Tuy nhiên, giao thức Bitcoin không thực thi tính toàn vẹn của sơ đồ lưu trữ KV này. BitVM giải quyết vấn đề này bằng cách sử dụng bằng chứng gian lận để phát hiện các Provers độc hại. Nếu Prover đưa ra tuyên bố không hợp lệ hoặc sử dụng bộ lưu trữ KV bị lỗi, những người khác có thể bắt đầu giao dịch trên blockchain Bitcoin để báo cáo hành vi sai trái của Prover và tịch thu tài sản đặt cọc của Prover.

Tóm lại, Bitcoin đang đối mặt với những thách thức đáng kể, và trong khi có nhiều đề xuất được đưa ra để giải quyết chúng, việc nhận được sự chấp nhận nhanh chóng từ cộng đồng Bitcoin là không tưởng. Những thay đổi giao thức không thể đạt được trong thời gian ngắn, phản ánh cả sức mạnh và hạn chế của sự phân quyền và bảo mật của Bitcoin. Tiềm năng của SNARKs và STARKs đang tạo ra sự phấn khích đáng kể trong cộng đồng. BitVM dường như là phương pháp hứa hẹn nhất để tích hợp xác minh SNARK trong trung và dài hạn, mặc dù cần thêm nghiên cứu và phát triển để trở nên hoàn toàn thực tế. Tái kích hoạt opcode OP_CAT là một con đường khác để khám phá, nhưng cần phải chứng minh rằng lợi ích của việc kích hoạt lại vượt qua rủi ro, và xác định những opcode đơn giản nào có thể hỗ trợ xác minh SNARK hoặc các chức năng tương tự trong các tập lệnh Bitcoin. Cuối cùng, cộng đồng Bitcoin nhằm mục tiêu nâng cao tính thực tế của công nghệ và hỗ trợ nhiều trường hợp sử dụng hành động hơn.

Đọc nội dung gốc tại đây: https://www.youtube.com/watch?v=GrSCZmFuy7U

Disclaimer：

1. Bài viết này được sao chép từ [ Geek Web3], Tất cả bản quyền thuộc về tác giả gốc [Geek Web3]. Nếu có bất kỳ ý kiến phản đối về việc tái bản này, vui lòng liên hệ với Cổng Họcđội ngũ, và họ sẽ xử lý nhanh chóng.
2. Miễn trách nhiệm: Quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc sở hữu của tác giả và không đại diện cho bất kỳ lời khuyên đầu tư nào.
3. Các bài dịch sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài dịch là cấm.