Cảnh báo rủi ro: Đề phòng huy động vốn bất hợp pháp dưới danh nghĩa 'tiền điện tử' và 'blockchain'. — Năm cơ quan bao gồm Ủy ban Giám sát Ngân hàng và Bảo hiểm
Tìm kiếm
Đăng nhập
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt
BTC
ETH
HTX
SOL
BNB
Xem thị trường
Bùng nổ chuỗi khối và trạng thái
Nervos
特邀专栏作者
2019-05-24 10:00
Bài viết này có khoảng 4948 từ, đọc toàn bộ bài viết mất khoảng 8 phút
Tác giả của bài viết này, Jan, phân tích sự bùng nổ trạng thái của chuỗi khối bằng cách so sánh và phân tích lịch sử cũng như trạng thái của Bitcoin và Ethereum.

nếu nhưTrọng tâm của Lớp 1 phải là trạng thái hơn là tính toántiêu đề phụ

tình trạng

Mỗi nút đầy đủ trong mạng chuỗi khối sẽ để lại một số dữ liệu trên bộ lưu trữ cục bộ sau khi chạy trong mạng trong một khoảng thời gian. Chúng ta có thể chia chúng thành hai loại theo lịch sử và hiện tại:

  • Lịch sử — Cả dữ liệu khối và dữ liệu giao dịch đều là lịch sử và lịch sử là đường dẫn từ Genesis đến trạng thái hiện tại.

  • Trạng thái (tức là hiện tại) - nút đã xử lý xong từ Genesis

Kết quả cuối cùng được hình thành sau tất cả các khối và giao dịch cho đến độ cao hiện tại. Trạng thái luôn thay đổi với việc bổ sung các khối và giao dịch là nguyên nhân của sự thay đổi.

Vai trò của giao thức đồng thuận là đảm bảo rằng trạng thái hiện tại mà mỗi nút nhìn thấy là giống nhau thông qua một loạt trao đổi thông báo và cách để đạt được mục tiêu này là đảm bảo rằng lịch sử mà mỗi nút nhìn thấy là giống nhau. Miễn là lịch sử giống nhau (nghĩa là thứ tự của tất cả các giao dịch giống nhau), cách xử lý giao dịch giống nhau (thực hiện các giao dịch trong cùng một máy ảo xác định) và trạng thái hiện tại được nhìn thấy ở cuối là giống nhau. Khi chúng ta nói "blockchain là bất biến", điều đó có nghĩa là lịch sử của blockchain không thể bị can thiệp, ngược lại, trạng thái luôn thay đổi.

Thật thú vị, các chuỗi khối khác nhau lưu trữ lịch sử và trạng thái theo những cách khác nhau và sự khác biệt làm cho các chuỗi khối khác nhau hình thành các đặc điểm riêng của chúng. Vì chủ đề được thảo luận trong bài viết này là trạng thái và dữ liệu lịch sử ảnh hưởng đến trạng thái chủ yếu là các giao dịch (chứ không phải tiêu đề khối), cuộc thảo luận tiếp theo về lịch sử sẽ làtập trung giao dịchtiêu đề phụ

Ví dụ: Lịch sử và trạng thái của Bitcoin

Trạng thái của Bitcoin đề cập đến trạng thái hiện tại của sổ cái Bitcoin. Trạng thái của Bitcoin bao gồm UTXO (đầu ra giao dịch chưa được chi tiêu), mỗi UTXO đại diện cho một lượng Bitcoin nhất định và mỗi UTXO có một tên (scriptPubkey) được viết trên đó, ghi lại ai là chủ sở hữu của UTXO này. Nếu một sự tương tự được thực hiện, trạng thái hiện tại của Bitcoin là một túi đầy tiền vàng, mỗi đồng tiền được khắc tên của chủ sở hữu.

Lịch sử của Bitcoin bao gồm một loạt các giao dịch và cấu trúc chính trong giao dịch là đầu vào và đầu ra. Một giao dịch thay đổi trạng thái bằng cách đánh dấu một số UTXO có trong trạng thái hiện tại (những UTXO được tham chiếu bởi đầu vào giao dịch) là đã sử dụng, loại bỏ chúng khỏi bộ UTXO và sau đó thêm một số UTXO mới (đầu ra của giao dịch này) vào bộ UTXO.

Có thể thấy đầu ra (TXO, Transaction Output) của giao dịch Bitcoin chính xác là UTXO đã đề cập ở trên và UTXO chỉ là một TXO trong giai đoạn đặc biệt (chưa được chi tiêu). Bởi vì các thành phần tạo nên trạng thái của Bitcoin (UTXO) cũng là các thành phần tạo nên giao dịch (TXO). Do đó, Bitcoin có một đặc tính tuyệt vời:Trạng thái tại bất kỳ thời điểm nào là một tập hợp con của lịch sử, các loại dữ liệu chứa trong lịch sử và trạng thái có cùng thứ nguyên.Lịch sử giao dịch (tập hợp tất cả các giao dịch được đóng gói, nghĩa là tập hợp tất cả các TXO được tạo) là lịch sử của trạng thái (tập hợp các UTXO tương ứng với mỗi khối, cũng là tập hợp tất cả các TXO được tạo), lịch sử của Bitcoin Chỉ chứa các giao dịch.

Trong mạng Bitcoin, mỗi khối và mỗi UTXO sẽ tiếp tục chiếm không gian lưu trữ của nút. hiện tạiKích thước toàn bộ lịch sử của Bitcoin (kích thước của tất cả các khối được thêm vào) là khoảng 200G,VàKích thước của trạng thái chỉ khoảng 3G (bao gồm khoảng 50 triệu UTXO)tiêu đề phụ

Một ví dụ khác: Lịch sử và trạng thái Ethereum

Trạng thái của Ethereum, còn được gọi là "trạng thái thế giới", đề cập đến trạng thái hiện tại của sổ cái Ethereum. Trạng thái của Ethereum là một cây Merkle bao gồm các tài khoản (tài khoản là các lá), tài khoản không chỉ ghi lại số dư (đại diện cho một lượng ether nhất định) mà còn ghi lại dữ liệu của hợp đồng (chẳng hạn như dữ liệu của từng con mèo được mã hóa ). Trạng thái của Ethereum có thể được coi là một cuốn sổ cái lớn, cột đầu tiên của sổ cái là tên, cột thứ hai là số dư và cột thứ ba là dữ liệu hợp đồng.

Lịch sử của Ethereum cũng được tạo thành từ các giao dịch và cấu trúc chính bên trong giao dịch là:

  • đến - một tài khoản khác đại diện cho người gửi giao dịch

  • giá trị - lượng ether được thực hiện bởi giao dịch

  • dữ liệu - Thông tin tùy ý được thực hiện bởi giao dịch

Cách giao dịch thay đổi trạng thái là EVM tìm thấy tài khoản mà giao dịch được gửi tới:

1. Tính số dư mới của tài khoản mục tiêu theo giá trị của giao dịch;
2. Truyền dữ liệu do giao dịch mang theo dưới dạng tham số cho hợp đồng thông minh của tài khoản đích, chạy logic của hợp đồng thông minh và có thể sửa đổi trạng thái bên trong của bất kỳ tài khoản nào trong quá trình hoạt động để tạo trạng thái mới;
3. Tạo một lá mới để lưu trữ trạng thái mới và cập nhật cây Merkle trạng thái.

Có thể thấy rằng lịch sử và cấu trúc giao dịch của Ethereum rất khác so với Bitcoin. Trạng thái của Ethereum bao gồm các tài khoản, trong khi các giao dịch bao gồm thông tin kích hoạt thay đổi tài khoản. Trạng thái và giao dịch ghi lại các loại dữ liệu hoàn toàn khác nhau. Không có mối quan hệ tập hợp con và tập hợp con nào giữa hai trạng thái này.Các loại dữ liệu chứa trong lịch sử và trạng thái là hai chiều, không có mối quan hệ cần thiết giữa kích thước lịch sử giao dịch và kích thước trạng thái. Sau khi giao dịch sửa đổi trạng thái, nó sẽ không chỉ tạo ra một trạng thái mới (các phần còn lại trong hộp đường liền nét trong hình), mà còn để lại trạng thái cũ (các phần còn lại trong hộp nét chấm trong hình) như một trạng thái lịch sử, vì vậy lịch sử của Ethereum không chỉ bao gồm các giao dịch mà còn chứa trạng thái lịch sử. Vì lịch sử và trạng thái thuộc về các chiều khác nhau, tiêu đề khối Ethereum không chỉ chứa gốc merkle của giao dịch mà còn cần chứa gốc merkle của trạng thái một cách rõ ràng. (Câu hỏi suy nghĩ: EOS sử dụng mô hình tài khoản tương tự như Ethereum, nhưng không bao gồm trạng thái Merkle Tree Root trong tiêu đề khối. Điều này tốt hay xấu?)

Mọi khối và mọi tài khoản trong Ethereum sẽ tiếp tục chiếm không gian lưu trữ của nút. Các nút Ethereum có nhiều chế độ khi đồng bộ hóa. Trong chế độ Lưu trữ, tất cả lịch sử và trạng thái sẽ được lưu giữ. Lịch sử bao gồm các giao dịch lịch sử và trạng thái lịch sử.Kích thước kết hợp của tất cả dữ liệu vượt quá 2TB;Trong chế độ Mặc định, trạng thái lịch sử sẽ bị cắt bớt và chỉ giao dịch lịch sử và trạng thái hiện tại mới được lưu cục bộ.Tất cả dữ liệu cộng lại lên tới khoảng 170G,TRONGKích thước lịch sử giao dịch là 150G và kích thước trạng thái hiện tại là 10G. Tất cả quản lý chi phí chung trong Ethereum được thống nhất theo mô hình thanh toán gas.Kích thước của giao dịch cần tiêu thụ lượng gas tương ứng và lượng gas được tiêu thụ bởi mỗi lệnh EVM không chỉ tính đến chi phí tính toán mà còn tính đến chi phí lưu trữ. Thông qua gaslimit của mỗi khối, tốc độ tăng trưởng của lịch sử và trạng thái bị hạn chế một cách gián tiếp.

ps.Một hiểu lầm phổ biến là "kích thước chuỗi khối" của Ethereum đã vượt quá 1T. Từ phân tích trên, chúng ta có thể thấy rằng "kích thước chuỗi khối" là một định nghĩa rất mơ hồ. Nếu bao gồm trạng thái lịch sử, nó sẽ vượt quá nó. Nhưng đối với tất cả các nút, không có vấn đề gì trong việc xóa trạng thái lịch sử. Bởi vì miễn là có Genesis và lịch sử giao dịch, trạng thái lịch sử bất cứ lúc nào cũng có thể được tính toán lại (bất kể thời gian cần thiết để tính toán). Dữ liệu thực sự có ý nghĩa là kích thước của dữ liệu cần thiết cho một nút đầy đủ. Bitcoin là 200G, Ethereum là 170G, cả hai về cơ bản giống nhau và có thể được cài đặt trên một máy chủ đám mây có cấu hình trung bình. Việc giảm các nút không phải do sự gia tăng dung lượng lưu trữ (nguyên nhân gốc rễ là chi phí tính toán trong quá trình đồng bộ hóa, sẽ không được mở rộng ở đây). Xem xét rằng độ dài lịch sử của Ethereum (dấu thời gian của khối hiện tại trừ đi dấu thời gian của nguồn gốc) ít hơn một nửa so với Bitcoin, có thể thấy rằng lịch sử và quy mô trạng thái của Ethereum phát triển nhanh hơn.

Bi kịch của (Lưu trữ) Commons: Phiên bản Chuỗi khối của Bi kịch của Commons
Bi kịch của tài sản chung đề cập đến một tình huống trong đó một nguồn tài nguyên được chia sẻ hữu hạn bị mọi người tiêu thụ quá mức mà không có bất kỳ hạn chế nào đối với việc sử dụng nó. Bộ nhớ được trả bởi các nút blockchain để lưu giữ lịch sử và trạng thái chỉ là một tài nguyên được chia sẻ như vậy.

Có ba loại tài nguyên được tiêu thụ bởi các nút blockchain để xử lý giao dịch, CPU, lưu trữ và băng thông mạng. CPU và băng thông là các tài nguyên sẽ được làm mới trong mỗi khối. Chúng ta có thể nghĩ rằng có cùng số lượng CPU và băng thông khả dụng trong mỗi khoảng thời gian của khối. CPU và băng thông được tiêu thụ trong khối trước đó sẽ không làm cho khối tiếp theo Ít CPU hơn và băng thông có sẵn cho chunk. Đối với các tài nguyên có thể làm mới, chúng tôi có thể bồi thường cho các nút bằng khoản thanh toán phí giao dịch một lần.

Không giống như CPU ​​và băng thông, bộ nhớ là tài nguyên bị chiếm dụng. Bộ nhớ bị chiếm giữ trong một khối không thể được người dùng khác sử dụng trong các khối tiếp theo trừ khi người dùng chủ động giải phóng nó. Các nút cần trả phí lưu trữ liên tục, nhưng người dùng không cần trả phí lưu trữ liên tục (hãy nhớ rằng phí giao dịch chỉ cần thanh toán một lần). Người dùng chỉ cần trả một khoản phí nhỏ khi ghi dữ liệu vào chuỗi khối và họ có thể sử dụng vĩnh viễn kho lưu trữ có tính khả dụng vượt xa Amazon S3 và chi phí lưu trữ vĩnh viễn vô hạn của nó cần do tất cả các nút đầy đủ trong mạng chuỗi khối chịu.

Do sự tồn tại của nhiều DApp khác nhau trên Ethereum, Bi kịch của (Lưu trữ) Commons tương đối nghiêm trọng hơn. Ví dụ, trongTại khối 5700001 (30/05/2018), 5 hợp đồng có trạng thái được sử dụng nhiều nhấtĐúng:

1.EtherDelta, 5.09%
2.IDEX, 4.17%
3.CryptoKitties, 3.05%
4.ENS, 1.92%
5.EOS Sale, 1.73%

Thú vị hơn là cái cuối cùng, EOS Sale. Mặc dù quá trình huy động vốn từ cộng đồng của EOS đã hoàn tất và các mã thông báo của EOS đã được lưu hành trên chuỗi EOS, các bản ghi về hoạt động huy động vốn từ cộng đồng của EOS vẫn tồn tại mãi mãi trên các nút Ethereum, tiêu tốn tài nguyên lưu trữ của toàn bộ nút Ethereum.

Có thể thấy, nếu không có sự quản lý, tài nguyên lưu trữ của blockchain sẽ bị lạm dụng một cách cố ý hoặc vô ý. Trong một mô hình kinh tế được thiết kế tốt, người dùng phải chịu chi phí sử dụng bộ nhớ,tiêu đề phụ

vụ nổ trạng thái

Cả dữ liệu lịch sử và trạng thái đều chiếm tài nguyên lưu trữ. Thông qua phân tích ở trên về Bitcoin và Ethereum (mô hình trạng thái của các chuỗi khối khác về cơ bản có thể được tóm tắt là một trong hai), chúng ta có thể thấy rằng mặc dù chúng quản lý sự phát triển của lịch sử và trạng thái, nhưng toàn bộ lịch sử và trạng thái không có sự kiểm soát nào đối với kích thước và những dữ liệu này sẽ tiếp tục tích lũy vô tận, làm cho tài nguyên lưu trữ cần thiết để chạy một nút đầy đủ ngày càng lớn hơn. Nâng cao ngưỡng hoạt động của các nút đầy đủ sẽ khiến mạng ngày càng ít phi tập trung hơn, đây là điều chúng tôi không muốn thấy.

Bạn có thể nói, chẳng lẽ sự cải thiện của mức độ trung bình của phần cứng sẽ vượt quá tốc độ tích lũy của lịch sử và địa vị? Câu trả lời của tôi rất khó xảy ra:

Từ biểu đồ này, chúng ta có thể thấy rằng khi mạng Ethereum phát triển, lượng dữ liệu trạng thái được tích lũy sẽ tăng theo cấp số nhân. Phải mất 10 năm để dữ liệu trạng thái của Bitcoin tích lũy từ 0 đến 3G; mất 4 năm để dữ liệu trạng thái của Ethereum tích lũy từ 0 đến 10G; và đây là trước khi chúng tôi giải quyết vấn đề Khả năng mở rộng và chuỗi khối vẫn còn một tỷ lệ tăng trưởng trường hợp công nghệ thích hợp.Khi chúng tôi giải quyết vấn đề về khả năng mở rộng, khi chuỗi khối thực sự được áp dụng rộng rãi và số lượng DApp và người dùng bùng nổ, lịch sử chuỗi khối và dữ liệu trạng thái sẽ tích lũy với tốc độ nào?

Đây là vấn đề bùng nổ trạng thái, mà chúng tôi phân loại là vấn đề hậu khả năng mở rộng, bởi vì nó sẽ rất rõ ràng sau khi giải quyết vấn đề Khả năng mở rộng. Lần đầu tiên chúng tôi nhận thấy vấn đề này khi triển khai kịch bản chuỗi giấy phép, bởi vìHiệu suất của chuỗi được phép cao hơn nhiều so với chuỗi công khai, chỉ trong giai đoạn hậu mở rộng. (Câu hỏi tư duy: Chuỗi quyền giải quyết vấn đề bùng nổ trạng thái như thế nào?)

Việc tích lũy dữ liệu lịch sử tương đối dễ xử lý. Trong tương lai, nó có thể được nén bằng các công nghệ như Điểm kiểm tra phi tập trung hoặc bằng chứng không kiến ​​thức. Trước đó, nút đầy đủ thậm chí có thể loại bỏ lịch sử trực tiếp mà vẫn hoạt động bình thường. Việc tích lũy dữ liệu trạng thái rất rắc rối, bởi vì đó là dữ liệu cần thiết cho hoạt động của nút đầy đủ.

Nhiều dự án blockchain đã nhìn thấy vấn đề này và đề xuất một số giải pháp. EOS RAM là một nỗ lực hữu ích để giải quyết vấn đề bùng nổ trạng thái: RAM đại diện cho tài nguyên bộ nhớ có sẵn cho máy chủ siêu nút, cho dù đó là tài khoản, trạng thái hợp đồng hay mã, nó cần chiếm một lượng RAM nhất định để chạy. Thiết kế của RAM cũng có nhiều vấn đề, nó cần được mua thông qua thị trường giao dịch tích hợp, không thể chuyển nhượng và không thể cho thuê, nó kết hợp các yêu cầu bộ nhớ ngắn hạn trong quá trình thực hiện hợp đồng và các yêu cầu lưu trữ dài hạn của trạng thái hợp đồng và tổng dung lượng RAM không được chỉ định. Các quy tắc được xác định phụ thuộc nhiều hơn vào cấu hình phần cứng mà siêu nút có thể chịu hơn là chi phí của không gian đồng thuận.

Cộng đồng Ethereum cũng thấy vấn đề này và hỏiGiải pháp cho thuê kho bãi: Người dùng phải trả trước tiền thuê để sử dụng tài nguyên lưu trữ. Chiếm tài nguyên lưu trữ sẽ tiếp tục tiêu tốn tiền thuê này. Thời gian chiếm giữ càng lâu, người dùng càng phải trả nhiều tiền thuê. Có hai vấn đề với kế hoạch Cho thuê kho lưu trữ:

1. Tiền nhà trả trước một ngày sẽ dùng hết, xử lý thế nào với tình trạng kín phòng lúc này? Chính xác là để giải quyết vấn đề này, Storage Rent cần các cơ chế như phục hồi để bổ sung, điều này làm tăng độ phức tạp của thiết kế, giảm đáng kể tính bất biến của hợp đồng thông minh và cũng gây rắc rối cho trải nghiệm người dùng;

2. Mô hình trạng thái của Ethereum là mô hình trạng thái chia sẻ, không phảiFirst-class State. Lấy Mã thông báo ERC20 làm ví dụ, tất cả hồ sơ tài sản của người dùng được lưu trữ trong bộ lưu trữ của một hợp đồng ERC20 duy nhất.Trong trường hợp này, ai sẽ trả tiền thuê?

Liên kết gốc:

Liên kết gốc:https://talk.nervos.org/t/top...


公链
Chào mừng tham gia cộng đồng chính thức của Odaily
Nhóm đăng ký
https://t.me/Odaily_News
Tài khoản chính thức
https://twitter.com/OdailyChina