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:

Triết lý thiết kế của Ethereum (1)

Vitalik Buterin

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

Mặc dù nhiều khái niệm về Ethereum đã được sử dụng và thử nghiệm trên các loại tiền điện tử trước đó (chẳng hạn như Bitcoin) trong 5 năm, Ethereum vẫn khác với các phương pháp phổ biến về cách xử lý một số chức năng giao thức nhất định.

Tiêu đề ban đầu: "Cơ sở lý luận về thiết kế"

Tác giả gốc: Vitalik Buterin

Bản tổng hợp gốc: kim & Ajian, người đam mê Ethereum

Mặc dù nhiều khái niệm về Ethereum đã được sử dụng trong các loại tiền điện tử trước đó (chẳng hạn như Bitcoin) và nó đã được thử nghiệm trong 5 năm, nhưng xét về cách xử lý một số chức năng giao thức nhất định, Ethereum vẫn rất khác so với các phương thức thông thường. Hơn nữa, Ethereum có thể được sử dụng để phát triển các công cụ kinh tế hoàn toàn mới vì nó có nhiều tính năng mà các hệ thống khác không có. Bài viết này sẽ trình bày chi tiết tất cả các lợi ích tiềm năng của Ethereum, cũng như một số khía cạnh gây tranh cãi khi xây dựng giao thức Ethereum. Ngoài ra, những rủi ro tiềm ẩn của giải pháp và giải pháp thay thế của chúng tôi cũng sẽ được chỉ ra.

Nguyên tắc

Ether Thiết kế của giao thức Fang tuân theo các nguyên tắc sau:

1. Mô hình phức tạp Sandwich (còn được dịch là "mô hình phân lớp phức tạp"): Chúng tôi tin rằng giao thức cơ bản của Ethereum phải đơn giản nhất có thể và thiết kế giao diện phải dễ hiểu (cho dù đó là giao diện ngôn ngữ lập trình cấp cao dành cho nhà phát triển hay giao diện người dùng). Những phần phức tạp không thể tránh khỏi nên được đặt ở lớp giữa. Lớp giữa không phải là một phần của sự đồng thuận cốt lõi và vô hình đối với người dùng cuối. Nó bao gồm: trình biên dịch ngôn ngữ cấp cao, tập lệnh tuần tự hóa và giải tuần tự hóa tham số, mô hình cấu trúc dữ liệu lưu trữ, giao diện lưu trữ Leveldb và giao thức mạng, v.v. Tất nhiên, ranh giới phân biệt không hoàn toàn rõ ràng và đôi khi cần phải điều chỉnh cho phù hợp.

2.Quyền tự do: Người dùng không nên bị hạn chế sử dụng Giao thức Ethereum, cũng không nên có bất kỳ nỗ lực nào nhằm ưu tiên hỗ trợ hoặc không hỗ trợ các hợp đồng hoặc giao dịch Ethereum nhất định. Điều này tương tự như nguyên tắc chỉ đạo đằng sau khái niệm "trung lập ròng". Giao thức giao dịch Bitcoin không tuân theo nguyên tắc này: giao thức giao dịch Bitcoin không khuyến khích "các mục đích ngoài nhãn" của chuỗi khối (ví dụ: lưu trữ dữ liệu, siêu giao thức) (lưu ý hiệu đính: Ý nghĩa ban đầu của ngoài nhãn hiệu là sử dụng một loại thuốc điều trị một tình trạng khác với chỉ định đã được phê duyệt, chẳng hạn như sử dụng thuốc giảm ho để điều trị chứng đau đầu); và đôi khi, nó được sử dụng - Thay đổi lớp giao thức (chẳng hạn như giới hạn độ dài của trường OP_RETURN ở mức 40 byte) để tấn công các ứng dụng sử dụng blockchain theo cách "trái phép" (Ghi chú hiệu đính: Đây là một sự châm biếm đối với cộng đồng Bitcoin kiểm duyệt xu hướng Bitcoin trong việc sử dụng blockchain). Do đó, trong Ethereum, chúng tôi kiên quyết ủng hộ việc chỉ sử dụng phí giao dịch để đạt được cách tiếp cận gần như tương thích với khuyến khích - người dùng tiêu thụ càng nhiều tài nguyên trên mạng thì mức giá mà họ phải trả càng cao, tức là ngay cả khi họ hoặc cô ấy tự chịu chi phí (tức là Thuế Pigou).

3. Khái quát hóa: Các tính năng và mã hoạt động của giao thức Ethereum phải phản ánh các khái niệm cấp thấp ở mức độ lớn nhất (ví dụ: như các hạt cơ bản) để chúng có thể được kết hợp theo ý muốn, bao gồm cả những thứ có vẻ vô dụng ngày nay nhưng có thể hữu ích trong tương lai. Hơn nữa, các khái niệm cấp thấp có thể được thực hiện hiệu quả hơn bằng cách loại bỏ các chức năng không cần thiết. Một ví dụ về việc tuân theo nguyên tắc này là chúng tôi đã chọn opcode LOG làm cách cung cấp thông tin cho dapp, thay vì ghi lại tất cả các giao dịch và tin nhắn như trước đây. Trong những ngày đầu, khái niệm "thông báo" hoàn toàn là một tập hợp của nhiều khái niệm. Nó bao gồm "lời gọi hàm" và "thông tin sự kiện (sự kiện) được những người quan sát bên ngoài quan tâm" và cả hai đều hoàn toàn có thể tách rời.

4. Không có đặc điểm nào là đặc điểm lớn nhất: Để tuân theo nguyên tắc khái quát hóa, chúng tôi Từ chối nhúng các trường hợp sử dụng nâng cao như một phần của giao thức, ngay cả đối với các trường hợp sử dụng được sử dụng thường xuyên. Nếu một người thực sự muốn triển khai các trường hợp sử dụng này, các giao thức phụ có thể được tạo trong hợp đồng (ví dụ: tiền tệ phụ dựa trên Ethereum, chuỗi bên Bitcoin/Litecoin/Dogecoin, v.v.). Ví dụ: Ethereum thiếu chức năng “khóa thời gian” tương tự như Bitcoin. Tuy nhiên, chức năng này có thể được mô phỏng thông qua giao thức sau: người dùng gửi gói dữ liệu đã ký đến một hợp đồng cụ thể để xử lý và nếu gói dữ liệu hợp lệ trong hợp đồng cụ thể thì chức năng tương ứng sẽ được thực thi.

5. Không ngại rủi ro: Chúng tôi sẵn sàng chấp nhận rủi ro cao hơn nếu việc tăng rủi ro mang lại lợi ích đáng kể (ví dụ: chuyển đổi trạng thái phổ quát, giảm 50 lần thời gian chặn, hiệu quả đồng thuận, v.v.). Những nguyên tắc này hướng dẫn sự phát triển của Ethereum, nhưng chúng không mang tính tuyệt đối; trong một số trường hợp, để giảm thời gian phát triển hoặc không muốn thực hiện quá nhiều thay đổi cùng một lúc, nó cũng sẽ khiến chúng ta trì hoãn một số thay đổi nhất định và để chúng tự động thực hiện. phiên bản tương lai để sửa đổi.

Giao thức lớp blockchain

Phần này mô tả những thay đổi đối với giao thức lớp blockchain trong Ethereum, bao gồm cách thức hoạt động của các khối và giao dịch, cách thức hoạt động, cách dữ liệu được tuần tự hóa và lưu trữ, cơ chế đằng sau tài khoản.

Tài khoản, không phải UTXO 1

Bitcoin và nhiều biến thể của nó, tất cả số dư của người dùng Thông tin được lưu trữ trong cấu trúc UTXO, và toàn bộ trạng thái của hệ thống bao gồm một chuỗi "đầu ra chưa tiêu" (bạn có thể coi những "đầu ra chưa tiêu" này như những đồng tiền) (Lưu ý hiệu đính: Một phép ẩn dụ tốt hơn có thể là "kiểm tra".). Mỗi UTXO có một chủ sở hữu và thuộc tính giá trị riêng. Khi một giao dịch sử dụng nhiều UTXO, nó cũng sẽ tạo ra một số UTXO mới và giao dịch đó phải tuân theo các yêu cầu về tính hợp lệ sau:

1. hợp lệ và không được sử dụng;

2. Chữ ký của giao dịch phải trùng với chữ ký của chủ sở hữu mỗi đầu vào

3. lớn hơn tổng giá trị sản lượng.

Do đó, trong hệ thống Bitcoin, "số dư" của người dùng là tất cả các mục mà khóa riêng của người dùng có thể sử dụng một cách hiệu quả dấu hiệu Tổng số UTXO. Hình dưới đây cho thấy quá trình đầu vào và đầu ra giao dịch trong hệ thống Bitcoin:

- Phương pháp kế toán ba bút toán được Bitcoin sử dụng-

Tuy nhiên, Ethereum đã từ bỏ giải pháp UTXO để chuyển sang một cách tiếp cận đơn giản hơn: sử dụng khái niệm trạng thái để lưu trữ một loạt tài khoản, mỗi tài khoản có số dư riêng và dữ liệu dành riêng cho Ethereum (mã và bộ nhớ trong). Nếu số dư tài khoản của người khởi tạo giao dịch đủ để trả phí giao dịch, giao dịch hợp lệ thì tài khoản của người khởi tạo giao dịch sẽ bị ghi nợ số tiền tương ứng và tài khoản nhận sẽ được ghi có số tiền này. Trong một số trường hợp, nếu có mã cần được thực thi trong tài khoản nhận, giao dịch sẽ kích hoạt việc thực thi mã và bộ nhớ trong của tài khoản có thể thay đổi, thậm chí có thể tạo và gửi thêm tin nhắn đến các tài khoản khác. , dẫn đến các giao dịch mới xảy ra.

Mặc dù Ethereum không áp dụng khái niệm UTXO, nhưng UTXO có một số ưu điểm:

1. Mức độ bảo vệ quyền riêng tư cao hơn: Nếu người dùng sử dụng địa chỉ mới cho mỗi giao dịch, sẽ khó liên kết các tài khoản với nhau. Điều này phù hợp với các hệ thống tiền tệ có yêu cầu bảo mật cao, nhưng nó không phù hợp với bất kỳ dapp nào. Bởi vì các dapp thường cần theo dõi các trạng thái ràng buộc phức tạp của người dùng và trạng thái của các dapp không thể phân chia đơn giản như trạng thái trong hệ thống tiền tệ.

2. Khả năng mở rộng tiềm năng: Về mặt lý thuyết, UTXO phù hợp hơn với một số loại mô hình khả năng mở rộng nhất định vì nó chỉ yêu cầu nắm giữ tiền tệ Miễn là chủ sở hữu có chứng chỉ Merkel thì có thể chứng minh quyền sở hữu tiền tệ của chính mình, ngay cả khi tất cả mọi người (kể cả chính họ) quên dữ liệu này, người này sẽ là người duy nhất thực sự bị thiệt hại, còn những người khác sẽ không bị ảnh hưởng. Trong hệ thống tài khoản Ethereum, nếu mọi người đều mất phần cây Merkle tương ứng với một tài khoản thì tài khoản đó sẽ không thể xử lý bất kỳ tin nhắn nào có thể ảnh hưởng đến nó, kể cả các tin nhắn được gửi đến nó và nó sẽ không thể xử lý. họ. Tuy nhiên, không chỉ UTXO mới có thể mở rộng mà còn có nhiều cách để mở rộng mà không cần dựa vào UTXO (không mở rộng ở đây, ghi chú của người dịch).

Các lợi ích của tài khoản bao gồm:

1. Dung lượng lớn: Nếu một tài khoản có 5 UTXO và chế độ UTXO được chuyển đổi sang chế độ tài khoản thì dung lượng cần thiết sẽ giảm từ 300 byte xuống 30 byte. Cách tính cụ thể như sau: 300 = (20+32+8) * 5 (20 là số byte địa chỉ, 32 là số byte TX ID, 8 là số byte mà mệnh giá chiếm giữ); 20 + 8 + 2 ( 20 là số byte địa chỉ, 8 là số byte giá trị số dư tài khoản và 2 là số byte nonce); nhưng số tiền tiết kiệm thực tế không lớn vì tài khoản cần phải có được lưu trữ trong cây Patricia. Ngoài ra, các giao dịch trong Ethereum nhỏ hơn so với giao dịch trong Bitcoin (100 byte trong Ethereum, 200-250 byte trong Bitcoin), vì mỗi giao dịch chỉ cần tạo một tham chiếu, một chữ ký và một đầu ra.

2. Có thể hoán đổi cho nhau nhiều hơn: Cấu trúc UTXO không có khái niệm về lớp blockchain nên dù là công nghệ hay về mặt pháp lý thì đều như vậy Việc thiết lập danh sách đỏ/danh sách đen và phân biệt những "kết quả đầu ra hợp lệ" này dựa trên nguồn của chúng là không thực tế lắm.

3. Tính đơn giản: Mã hóa Ethereum đơn giản và dễ hiểu hơn, đặc biệt khi nói đến các tập lệnh phức tạp. Mặc dù bất kỳ ứng dụng phi tập trung nào cũng có thể được triển khai (miễn cưỡng) bằng phương pháp UTXO, nhưng về cơ bản, phương pháp này cung cấp cho tập lệnh khả năng giới hạn các loại UTXO mà một UTXO nhất định có thể xuất ra và các điều kiện sử dụng nó (chẳng hạn như nhu cầu bao gồm Merkle cây Bằng chứng để giúp ứng dụng tương ứng của tập lệnh có khả năng thay đổi trạng thái gốc). Do đó, việc triển khai UTXO phức tạp hơn nhiều so với cách Ethereum sử dụng tài khoản.

4. Light client: Light client có thể truy cập tất cả dữ liệu liên quan đến tài khoản bất cứ lúc nào bằng cách quét cây trạng thái trong chỉ định phương hướng. . Trong mô hình UTXO, mỗi giao dịch yêu cầu một tham chiếu khác nhau, điều này chắc chắn gây khó khăn cho các ứng dụng dapp chạy dài sử dụng cơ chế lan truyền trạng thái gốc UTXO được đề cập ở trên.

Chúng tôi tin rằng lợi ích của các tài khoản vượt xa các lựa chọn thay thế, đặc biệt đối với các dapp mà chúng tôi muốn hỗ trợ có thể chứa trạng thái và mã tùy ý. Ngoài ra, dựa trên nguyên tắc hướng dẫn "không có tính năng nào là tính năng lớn nhất", chúng tôi tin rằng nếu người dùng thực sự quan tâm đến quyền riêng tư, họ có thể xây dựng một "bộ trộn và coinjoin" được mã hóa thông qua giao thức gói chữ ký trong hợp đồng. .

Điểm yếu của phương thức tài khoản là: để ngăn chặn các cuộc tấn công lặp lại (ám chỉ việc cho phép thực hiện lặp đi lặp lại cùng một giao dịch), mỗi giao dịch phải có một "nonce" (số sê-ri). Do đó, mỗi tài khoản phải có một giá trị nonce được cập nhật theo thời gian thực. Mỗi giao dịch mới sẽ tăng giá trị nonce của tài khoản lên 1 làm giá trị nonce của chính nó (và cập nhật giá trị nonce của tài khoản theo giá trị này sau khi giao dịch được xử lý) (ghi chú hiệu đính) : Trong chế độ tài khoản, nếu giao dịch không đi kèm với số nhận dạng có thể sử dụng được này, giao dịch có thể được xử lý nhiều lần để tài khoản nhận có thể được thu thập nhiều lần mà không phải trả bất kỳ chi phí nào, trong khi tài khoản gửi có thể bị cạn kiệt. nonce của tài khoản Ethereum được tăng lên khi giao dịch bắt đầu được xử lý, giải quyết vấn đề này). Điều này có nghĩa là ngay cả những tài khoản không còn được sử dụng cũng không thể bị xóa khỏi trạng thái tài khoản. Một cách đơn giản để giải quyết vấn đề này là yêu cầu các giao dịch bao gồm số khối để chúng không thể được phát lại sau một khoảng thời gian nhất định và đặt lại số nonce sau mỗi khoảng thời gian nhất định.

Nếu bạn muốn xóa một tài khoản ở trạng thái (chẳng hạn như một tài khoản đã không được sử dụng trong một thời gian dài), trước tiên bạn phải "ping" chúng ra và chi phí cho việc quét hoàn toàn giao thức blockchain là rất cao. Chúng tôi không triển khai cơ chế này trên phiên bản 1.0 trở lên có thể sử dụng cơ chế này.

Lưu ý hiệu đính: Đây là lý do kỹ thuật cho vấn đề "bùng nổ trạng thái" mà Ethereum sẽ gặp phải trong tương lai: tất cả dữ liệu trạng thái phải được lưu hoàn toàn và không thể xóa tài khoản một cách hợp lý. Là một giao thức blockchain, các nút Ethereum không chỉ phải đạt được sự đồng thuận về thứ tự giao dịch (giao dịch) mà còn phải đạt được sự đồng thuận về trạng thái toàn cầu (dưới dạng gốc trạng thái cần được đưa vào tiêu đề khối. Vì vậy, , nếu muốn xóa trạng thái thì cũng cần có sự đồng thuận của toàn mạng, nếu không sẽ rơi vào tình trạng phân chia

Ghi chú hiệu đính: Phương pháp sử dụng nonce này để đánh dấu thứ tự giao dịch tài khoản cũng khiến các giao dịch của người dùng phải được thực hiện một cách tuần tự. Nếu một giao dịch không thể được xử lý thì các giao dịch không được xử lý tiếp theo cũng sẽ không thể được xử lý. .weixin.qq.com/s?__biz=MzIwODA3NDI5MA==& mid=2652525625&idx=1&sn=11c63432a570e5a17042269d5a6a0e73&chksm=8ce65764bb91de72c978315d780f671 e77a2a494b9b20779a1e6979920c87 0e4f1b6b4dbc713&scene=21#wechat_redirect" textvalue="Bài viết này" tab="innerlink" hasload="1">Bài viết này. span>

Cây Merkel Patricia (MPT)

Cây Merkle Patricia/trie, do Alan Reiner nghĩ ra và triển khai trong giao thức Ripple, là cấu trúc dữ liệu chính của Ethereum và được dùng để lưu trữ tất cả trạng thái tài khoản cũng như từng dữ liệu Giao dịch và biên nhận trong các khối. MPT là sự kết hợp của cây Merkle và cây Patricia. Cấu trúc được tạo bằng cách kết hợp hai cây này có các thuộc tính sau:

1 Bất kỳ bộ khóa nào -Băm gốc. value tương ứng với cặp giá trị là duy nhất. Nếu bạn muốn nói dối rằng một cặp key-value nào đó tồn tại trong một cây nào đó thì chắc chắn nó sẽ bị nhìn thấu (trừ khi kẻ tấn công có sức mạnh tính toán khoảng 2^128).

2. Độ phức tạp về thời gian của việc thêm, xóa và sửa đổi một cặp khóa-giá trị là logarit.

MPT cung cấp cho chúng ta một "dấu vân tay" hiệu quả, dễ cập nhật, đại diện cho toàn bộ cây trạng thái. Mô tả chi tiết hơn về MPT: https://github.com/ethereum/wiki/wiki/Patricia-Tree.

Các quyết định thiết kế cụ thể của MPT như sau:

1. có hai loại nút:nút KV và nút rời rạc. Sự hiện diện của các nút KV cải thiện hiệu quả vì chúng có thể đóng vai trò là "phím tắt" để nén chiều cao của cây nếu cây thưa thớt ở một khu vực cụ thể (đọc đặc tả MPT để biết thêm chi tiết).

2. Các nút rời rạc có dạng thập lục phân, không phải nhị phân: Điều này làm cho việc tìm kiếm hiệu quả hơn. không lý tưởng vì hiệu quả tra cứu của cây hex có thể được mô phỏng ở dạng nhị phân bằng cách lưu trữ các nút theo lô. Tuy nhiên, việc triển khai cấu trúc cây MPT rất dễ xảy ra lỗi và cuối cùng sẽ dẫn đến ít nhất một gốc trạng thái không khớp, vì vậy chúng tôi đã quyết định tạm dừng các thay đổi cho đến phiên bản 1.1.

3. Không có sự khác biệt giữa giá trị trống và giá trị không phải thành viên: Điều này được thực hiện để đơn giản Về mặt logic, giá trị (cân bằng) số tài khoản không được kích hoạt trong Ethereum mặc định là 0 và các chuỗi trống cũng được biểu thị bằng 0. Tuy nhiên, cần nhấn mạnh rằng điều này làm mất đi tính linh hoạt và do đó không tối ưu.

4. Sự khác biệt giữa điểm đầu cuối (điểm cuối) và điểm không đầu cuối:Về mặt kỹ thuật, nó xác định xem một nút có phải là điểm cuối hay không point. Điều này là không cần thiết, vì tất cả các cây trong Ethereum đều được sử dụng để lưu trữ dữ liệu có độ dài cố định (tức là độ dài của khóa), nhưng để tăng tính linh hoạt, chúng ta vẫn sẽ thêm mã định danh này để mong đợi việc triển khai. MPT của Ethereum Có thể được áp dụng giống như các loại tiền điện tử khác.

5. Sử dụng SHA3(k) làm khóa trong "Cây bảo mật" (cây trạng thái và cây lưu trữ tài khoản):Sử dụng SHA3(k) , các cuộc tấn công DoS trở nên khó khăn hơn nhiều bằng cách tạo ra nhiều tài khoản (tài khoản có thể có tới 64 cấp độ trong cây trạng thái!) và liên tục gọi các mã opcode SLOAD và SSTORE. Lưu ý rằng điều này cũng khiến việc liệt kê cây trở nên khó khăn hơn; nếu bạn muốn kích hoạt khả năng liệt kê trên máy khách của mình, cách dễ nhất là duy trì ánh xạ cơ sở dữ liệu sha3(k) ->.

Ghi chú hiệu đính: Ý nghĩa ở đây là nếu k được dùng làm chìa khóa để lưu trữ dữ liệu trong cây Merkle thì khả năng phân phối của nó có thể rất thưa thớt và kẻ tấn công sẽ có thể dễ dàng Lập kế hoạch cho các tài khoản yêu cầu đường dẫn cây sâu để lưu trữ và liên tục gọi các hoạt động truy cập trạng thái trên các tài khoản này làm quá tải các nút trong mạng. Tuy nhiên, kết quả của hàm băm được phân phối ngẫu nhiên, với sha3(k ) làm khóa. sự phân bố các khóa đồng đều hơn và chiều cao của cây sẽ ngắn hơn).

Tính năng này cũng có những ưu và nhược điểm, một mặt nó có nghĩa là các cuộc tấn công DoS sẽ trở nên khó khăn hơn, mặt khác nó cũng khiến cho việc tấn công trở nên khó khăn hơn. Các đường dẫn truy cập cây trạng thái giao dịch hiếm khi trùng nhau, vì vậy mỗi lần tìm kiếm là trường hợp xấu nhất xét về độ phức tạp.

Ngoài ra, điều này cũng khiến MPT không phù hợp để đạt được "không trạng thái" (bản thân khối mang dữ liệu cần thiết để xác minh và người xác minh không cần phải có toàn cầu trạng thái), bởi vì Các đường dẫn truy cập trạng thái không trùng nhau và hiệu quả về mặt không gian của bằng chứng cũng là trường hợp xấu nhất. Tất nhiên, cũng có thể nói rằng bản thân hiệu quả không gian của bằng chứng cây Merkel chưa đủ cao

RLP

RLP (tiền tố độ dài đệ quy): tiền tố độ dài đệ quy.

Mã hóa RLP là định dạng tuần tự hóa chính trong Ethereum và nó được sử dụng ở mọi nơi: khối, giao dịch, trạng thái tài khoản và thông báo giao thức mạng. Xem mô tả chính thức về RLP để biết chi tiết: https://github.com/ethereum/wiki/wiki/RLP

RLP được dự định là một giải pháp nâng cao định dạng tuần tự hóa được đơn giản hóa, mục đích duy nhất của nó là lưu trữ các mảng byte lồng nhau 3. Không giống như các giải pháp hiện có như protobuf và BSON, RLP không xác định bất kỳ loại dữ liệu cụ thể nào, chẳng hạn như Boolean, float, double hoặc số nguyên. Nó chỉ đơn giản lưu trữ cấu trúc dưới dạng một mảng lồng nhau và giao thức xác định ý nghĩa của mảng đó. RLP không hỗ trợ rõ ràng các bộ sưu tập bản đồ. Đề xuất bán chính thức là sử dụng một mảng lồng nhau của [[k1, v1], [k2, v2], ...] k2 ... Sắp xếp chuỗi theo tiêu chí của chúng.

Một giải pháp có chức năng tương tự như RLP là protobuf hoặc BSON, là những thuật toán được sử dụng mọi lúc. Tuy nhiên, trong Ethereum, chúng tôi thích sử dụng RLP hơn vì: (1) dễ triển khai; (2) tính nhất quán của byte được đảm bảo tuyệt đối.

Bộ sưu tập cặp khóa-giá trị trong nhiều ngôn ngữ không có thứ tự rõ ràng và có nhiều trường hợp đặc biệt trong định dạng dấu phẩy động, có thể gây ra lỗi cùng một dữ liệu để tạo ra các bảng mã khác nhau và giá trị băm khác nhau. Thông qua thỏa thuận phát triển nội bộ, chúng tôi có thể đảm bảo rằng nó được thiết kế phù hợp với những mục tiêu này (đây là nguyên tắc chung cũng áp dụng cho các phần khác của mã, chẳng hạn như máy ảo). Bencode, mã hóa được BitTorrent sử dụng, có thể thay thế cho RLP. Tuy nhiên, nó sử dụng mã hóa thập phân, kém hơn một chút so với RLP nhị phân.

Thuật toán nén

Cả giao thức mạng và cơ sở dữ liệu đều sử dụng thuật toán nén tùy chỉnh. dữ liệu. Thuật toán có thể được mô tả như sau: sử dụng mã hóa độ dài chạy 4 cho 0 trong khi vẫn giữ các giá trị khác (ngoại trừ một số trường hợp đặc biệt như sha3(' ') ), ví dụ:

>>> nén('ngựa')

'ngựa'

>>> nén('con lừa rồng 1231231243') '

rồng lừa 1231231243'

>>> nén('\xf8\xaf\xf8\xab\xa0\x00\x00\x00\x00 \x00\x00 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00 \x00\x00\xbe{b\xd5\xcd\x8d\x87\x97')'

\xf8\xaf\xf8\xab\xa0\xfe\x9e\xbe{b \xd5\xcd \x8d\x87\x97'

>>> nén("\xc5\xd2F\x01\x86\xf7#<\x92~}\xb2\xdc\xc7 \x03\xc0 \xe5\x00\xb6S\xca\x82';{\xfa\xd8\x04]\x85\xa4p")

『\xfe\x01'

Trước khi thuật toán nén tồn tại, có một số trường hợp đặc biệt ở nhiều nơi trong giao thức Ethereum. Ví dụ: sha3 thường được xác định lại để sha3(' ')=' ', điều này loại bỏ nhu cầu lưu trữ. mã trong tài khoản và tiết kiệm được 64 byte. Tuy nhiên, gần đây tất cả các trường hợp đặc biệt khiến cấu trúc dữ liệu của Ethereum bị cồng kềnh đã bị loại bỏ và thay thế bằng cách thêm các chức năng lưu dữ liệu vào một lớp bên ngoài giao thức blockchain, tức là đưa nó vào giao thức mạng cũng như Chèn cơ sở dữ liệu người dùng. Điều này làm tăng tính mô-đun, đơn giản hóa lớp đồng thuận và làm cho việc cập nhật và triển khai liên tục các thuật toán nén tương đối đơn giản (ví dụ: nó có thể được phân biệt và triển khai theo số phiên bản của giao thức mạng).

Sử dụng cây (trie)

Nhắc nhở: Để hiểu được phần kiến thức này cần có người đọc hiểu Nguyên lý của bộ lọc Bloom 5 . Bạn có thể tìm thấy phần giới thiệu tại:

http://en.wikipedia.org/wiki/Bloom_filter

Mỗi vùng trong Ethereum blockchain Tiêu đề khối chứa các con trỏ tới ba cây: cây trạng thái, cây giao dịch và cây biên nhận.

• Cây trạng thái biểu thị toàn bộ trạng thái sau khi xử lý khối;

• Cây giao dịch đại diện cho tất cả các giao dịch trong khối, được khóa theo chỉ mục (ví dụ: k0: giao dịch được thực hiện đầu tiên, k1: giao dịch được thực hiện thứ hai)

• Cây biên nhận thể hiện biên nhận tương ứng cho mỗi giao dịch.

Biên nhận giao dịch là cấu trúc dữ liệu được mã hóa RLP:

[ medstate, gas_used, logbloom, logs 

Trong số đó:

• medstate: Sau khi xử lý giao dịch, gốc của cây trạng thái;

• gas_used: lượng gas sử dụng sau khi xử lý giao dịch;

• logs: là danh sách gồm nhiều phần tử [địa chỉ, [topic1, topic2...], data] . Các phần tử này được tạo bởi các opcodes LOG0 ... LOG4 được gọi trong quá trình thực hiện giao dịch (bao gồm cả các lệnh gọi chính và phụ); địa chỉ của hợp đồng đã tạo ra nhật ký có tối đa bốn chủ đề 32 byte; giá trị ;dữ liệu là một mảng byte có kích thước bất kỳ;

• logbloom: Bộ lọc Bloom bao gồm địa chỉ và chủ đề của tất cả nhật ký trong giao dịch.

Ngoài ra còn có bộ lọc Bloom trong tiêu đề khối, là kết quả OR của tất cả các bộ lọc Bloom của các giao dịch trong khối. Cấu trúc này làm cho giao thức Ethereum cực kỳ thân thiện với khách hàng.

Lưu ý:

1.UTXO: đầu ra giao dịch chưa được chi tiêu, nghĩa đen là : Đầu ra giao dịch chưa chi tiêu là đầu ra giao dịch không được bất kỳ giao dịch nào tham chiếu làm đầu vào. Nó là cấu trúc dữ liệu được sử dụng trong giao thức Bitcoin để lưu trữ thông tin giá trị (quyền sở hữu). --Ghi chú hiệu đính

2.Nonce, viết tắt của Số được sử dụng một lần hoặc Số một lần, trong mật mã, Nonce là một giá trị ngẫu nhiên tùy ý hoặc không lặp lại, chỉ được sử dụng một lần, trong công nghệ mã hóa Cả hai vectơ ban đầu và hàm băm mật mã đóng vai trò quan trọng trong việc đảm bảo rằng thông tin xác minh không được sử dụng lại trong các ứng dụng truyền thông của các giao thức xác minh khác nhau để chống lại các cuộc tấn công lặp lại. --Ghi chú của người dịch

3. Mảng lồng nhau: Tạo một mảng và điền vào mảng đó bằng các mảng khác. Ví dụ: mảng thú cưng:

var cats : String[] = ["Cat", "Beansprout", "Pumpkin", "Max"];var dogs : String[] = [ "Dog","Oly","Sib"];
var pet : String = [mèo, chó];

— —Ghi chú của người dịch

4. Mã hóa thời lượng chạy: mã hóa thống kê. Kỹ thuật chính là phát hiện các chuỗi bit hoặc ký tự lặp lại và thay thế chúng bằng số lần chúng xuất hiện. (Baidu Encyclopedia) - Translator's Note

5. Bộ lọc Bloom: Cấu trúc dữ liệu vectơ nhị phân được đề xuất bởi Howard Bloom vào năm 1970. Nó có hiệu quả về không gian và thời gian tốt và được sử dụng để phát hiện một phần tử không phải là thành viên của bộ. (Bách khoa toàn thư Baidu) - Ghi chú của người dịch