From a774d202ac7206e5a15cab478a5e377e9b988acf Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Sat, 14 Feb 2026 00:04:40 +0000 Subject: [PATCH 1/2] i18n(vi): translation import part 03 of 13 (23 files) --- .../pos/attestations/index.md | 92 ++ .../pos/block-proposal/index.md | 69 ++ .../consensus-mechanisms/pos/faqs/index.md | 172 +++ .../consensus-mechanisms/pos/gasper/index.md | 52 + .../docs/consensus-mechanisms/pos/index.md | 99 ++ .../consensus-mechanisms/pos/keys/index.md | 102 ++ .../pos/pos-vs-pow/index.md | 69 ++ .../pos/rewards-and-penalties/index.md | 91 ++ .../pos/weak-subjectivity/index.md | 39 + .../pos/withdrawal-credentials/index.md | 64 ++ .../docs/consensus-mechanisms/pow/index.md | 114 ++ .../consensus-mechanisms/pow/mining/index.md | 86 ++ .../dagger-hashimoto/index.md | 330 ++++++ .../mining/mining-algorithms/ethash/index.md | 1022 +++++++++++++++++ .../pow/mining/mining-algorithms/index.md | 42 + .../vi/developers/docs/dapps/index.md | 96 ++ .../block-explorers/index.md | 254 ++++ .../docs/data-and-analytics/index.md | 72 ++ .../index.md | 118 ++ .../docs/data-availability/index.md | 84 ++ .../data-structures-and-encoding/index.md | 32 + .../patricia-merkle-trie/index.md | 266 +++++ .../data-structures-and-encoding/rlp/index.md | 163 +++ 23 files changed, 3528 insertions(+) create mode 100644 public/content/translations/vi/developers/docs/consensus-mechanisms/pos/attestations/index.md create mode 100644 public/content/translations/vi/developers/docs/consensus-mechanisms/pos/block-proposal/index.md create mode 100644 public/content/translations/vi/developers/docs/consensus-mechanisms/pos/faqs/index.md create mode 100644 public/content/translations/vi/developers/docs/consensus-mechanisms/pos/gasper/index.md create mode 100644 public/content/translations/vi/developers/docs/consensus-mechanisms/pos/index.md create mode 100644 public/content/translations/vi/developers/docs/consensus-mechanisms/pos/keys/index.md create mode 100644 public/content/translations/vi/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md create mode 100644 public/content/translations/vi/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md create mode 100644 public/content/translations/vi/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md create mode 100644 public/content/translations/vi/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md create mode 100644 public/content/translations/vi/developers/docs/consensus-mechanisms/pow/index.md create mode 100644 public/content/translations/vi/developers/docs/consensus-mechanisms/pow/mining/index.md create mode 100644 public/content/translations/vi/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md create mode 100644 public/content/translations/vi/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md create mode 100644 public/content/translations/vi/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md create mode 100644 public/content/translations/vi/developers/docs/dapps/index.md create mode 100644 public/content/translations/vi/developers/docs/data-and-analytics/block-explorers/index.md create mode 100644 public/content/translations/vi/developers/docs/data-and-analytics/index.md create mode 100644 public/content/translations/vi/developers/docs/data-availability/blockchain-data-storage-strategies/index.md create mode 100644 public/content/translations/vi/developers/docs/data-availability/index.md create mode 100644 public/content/translations/vi/developers/docs/data-structures-and-encoding/index.md create mode 100644 public/content/translations/vi/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md create mode 100644 public/content/translations/vi/developers/docs/data-structures-and-encoding/rlp/index.md diff --git a/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/attestations/index.md b/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/attestations/index.md new file mode 100644 index 00000000000..dcfdcc46567 --- /dev/null +++ b/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/attestations/index.md @@ -0,0 +1,92 @@ +--- +title: "Các chứng thực" +description: "Mô tả về các chứng thực trên Ethereum bằng chứng cổ phần." +lang: vi +--- + +Một trình xác thực dự kiến sẽ tạo, ký và phát một chứng thực trong mỗi tham số epoch. Trang này phác thảo các chứng thực này trông như thế nào và cách chúng được xử lý và truyền đạt giữa các máy khách đồng thuận. + +## Chứng thực là gì? {#what-is-an-attestation} + +Mỗi [tham số epoch](/glossary/#epoch) (6,4 phút), một trình xác thực sẽ đề xuất một chứng thực cho mạng. Chứng thực dành cho một slot cụ thể trong tham số epoch. Mục đích của chứng thực là bỏ phiếu ủng hộ quan điểm của trình xác thực về chuỗi, cụ thể là khối được chứng minh hợp lệ gần đây nhất và khối đầu tiên trong tham số epoch hiện tại (được gọi là các điểm kiểm tra `nguồn` và `đích`). Thông tin này được kết hợp cho tất cả các trình xác thực tham gia, cho phép mạng đạt được sự đồng thuận về trạng thái của chuỗi khối. + +Chứng thực chứa các thành phần sau: + +- `aggregation_bits`: danh sách bit của các trình xác thực trong đó vị trí ánh xạ tới chỉ mục của trình xác thực trong ủy ban của họ; giá trị (0/1) cho biết liệu trình xác thực đã ký `dữ liệu` hay chưa (tức là liệu họ có đang hoạt động và đồng ý với người đề xuất khối hay không) +- `data`: các chi tiết liên quan đến chứng thực, như được định nghĩa bên dưới +- `signature`: một chữ ký BLS tổng hợp các chữ ký của các trình xác thực riêng lẻ + +Nhiệm vụ đầu tiên của một trình xác thực chứng thực là xây dựng `dữ liệu`. `Dữ liệu` chứa các thông tin sau: + +- `slot`: Số slot mà chứng thực đề cập đến +- `index`: Một số xác định ủy ban mà trình xác thực thuộc về trong một slot nhất định +- `beacon_block_root`: Hàm băm gốc của khối mà trình xác thực nhìn thấy ở đầu chuỗi (kết quả của việc áp dụng thuật toán lựa chọn phân nhánh) +- `source`: Một phần của phiếu bầu về tính kết luận cuối cùng cho biết những gì các trình xác thực xem là khối được chứng minh hợp lệ gần đây nhất +- `target`: Một phần của phiếu bầu về tính kết luận cuối cùng cho biết những gì các trình xác thực xem là khối đầu tiên trong tham số epoch hiện tại + +Khi `dữ liệu` được xây dựng, trình xác thực có thể lật bit trong `aggregation_bits` tương ứng với chỉ mục trình xác thực của chính họ từ 0 thành 1 để cho thấy rằng họ đã tham gia. + +Cuối cùng, trình xác thực ký chứng thực và phát nó lên mạng. + +### Chứng thực tổng hợp {#aggregated-attestation} + +Có một chi phí đáng kể liên quan đến việc chuyển dữ liệu này xung quanh mạng cho mỗi trình xác thực. Do đó, các chứng thực từ các trình xác thực riêng lẻ được tổng hợp trong các mạng con trước khi được phát đi rộng rãi hơn. Điều này bao gồm việc tổng hợp các chữ ký lại với nhau để một chứng thực được phát đi bao gồm `dữ liệu` đồng thuận và một chữ ký duy nhất được hình thành bằng cách kết hợp chữ ký của tất cả các trình xác thực đồng ý với `dữ liệu` đó. Điều này có thể được kiểm tra bằng cách sử dụng `aggregation_bits` vì điều này cung cấp chỉ mục của mỗi trình xác thực trong ủy ban của họ (có ID được cung cấp trong `dữ liệu`) có thể được sử dụng để truy vấn các chữ ký riêng lẻ. + +Trong mỗi tham số epoch, 16 trình xác thực trong mỗi mạng con được chọn làm `bộ tổng hợp`. Các bộ tổng hợp thu thập tất cả các chứng thực mà họ nghe được qua mạng gossip có `dữ liệu` tương đương với dữ liệu của chính họ. Người gửi của mỗi chứng thực phù hợp được ghi lại trong `aggregation_bits`. Sau đó, các bộ tổng hợp phát tổng hợp chứng thực tới mạng rộng hơn. + +Khi một trình xác thực được chọn làm người đề xuất khối, họ sẽ đóng gói các chứng thực tổng hợp từ các mạng con cho đến slot mới nhất trong khối mới. + +### Vòng đời đưa vào của chứng thực {#attestation-inclusion-lifecycle} + +1. Tạo +2. Truyền bá +3. Tổng hợp +4. Truyền bá +5. Đưa vào + +Vòng đời chứng thực được phác thảo trong sơ đồ dưới đây: + +![vòng đời chứng thực](./attestation_schematic.png) + +## Phần thưởng {#rewards} + +Các trình xác thực được thưởng khi gửi chứng thực. Phần thưởng chứng thực phụ thuộc vào các cờ tham gia (nguồn, đích và đầu), phần thưởng cơ bản và tỷ lệ tham gia. + +Mỗi cờ tham gia có thể là đúng hoặc sai, tùy thuộc vào chứng thực đã gửi và độ trễ đưa vào của nó. + +Tình huống tốt nhất xảy ra khi cả ba cờ đều đúng, trong trường hợp đó, một trình xác thực sẽ kiếm được (cho mỗi cờ đúng): + +`phần thưởng += phần thưởng cơ bản * trọng số cờ * tỷ lệ chứng thực cờ / 64` + +Tỷ lệ chứng thực cờ được đo bằng cách sử dụng tổng số dư hiệu dụng của tất cả các trình xác thực chứng thực cho cờ đã cho so với tổng số dư hiệu dụng đang hoạt động. + +### Phần thưởng cơ bản {#base-reward} + +Phần thưởng cơ bản được tính theo số lượng trình xác thực chứng thực và số dư ether đã đặt cọc hiệu dụng của họ: + +`phần thưởng cơ bản = số dư hiệu dụng của trình xác thực x 2^6 / SQRT(Số dư hiệu dụng của tất cả các trình xác thực đang hoạt động)` + +#### Độ trễ đưa vào {#inclusion-delay} + +Tại thời điểm các trình xác thực bỏ phiếu cho đầu chuỗi (`khối n`), `khối n+1` vẫn chưa được đề xuất. Do đó, các chứng thực tự nhiên được đưa vào **sau một khối**, vì vậy tất cả các chứng thực đã bỏ phiếu cho `khối n` là đầu chuỗi đều được đưa vào `khối n+1`, và **độ trễ đưa vào** là 1. Nếu độ trễ đưa vào tăng gấp đôi thành hai slot, phần thưởng chứng thực sẽ giảm một nửa, vì để tính phần thưởng chứng thực, phần thưởng cơ bản được nhân với nghịch đảo của độ trễ đưa vào. + +### Các kịch bản chứng thực {#attestation-scenarios} + +#### Thiếu Trình xác thực bỏ phiếu {#missing-voting-validator} + +Các trình xác thực có tối đa 1 tham số epoch để gửi chứng thực của họ. Nếu chứng thực bị bỏ lỡ trong tham số epoch 0, họ có thể gửi nó với độ trễ đưa vào trong tham số epoch 1. + +#### Thiếu Bộ tổng hợp {#missing-aggregator} + +Tổng cộng có 16 Bộ tổng hợp cho mỗi tham số epoch. Ngoài ra, các trình xác thực ngẫu nhiên đăng ký **hai mạng con trong 256 tham số epoch** và đóng vai trò dự phòng trong trường hợp thiếu các bộ tổng hợp. + +#### Thiếu người đề xuất khối {#missing-block-proposer} + +Lưu ý rằng trong một số trường hợp, một bộ tổng hợp may mắn cũng có thể trở thành người đề xuất khối. Nếu chứng thực không được đưa vào vì người đề xuất khối đã mất tích, người đề xuất khối tiếp theo sẽ lấy chứng thực tổng hợp và đưa nó vào khối tiếp theo. Tuy nhiên, **độ trễ đưa vào** sẽ tăng thêm một. + +## Đọc thêm {#further-reading} + +- [Các chứng thực trong đặc tả đồng thuận có chú thích của Vitalik](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata) +- [Các chứng thực trong eth2book.info](https://eth2book.info/capella/part3/containers/dependencies/#attestationdata) + +_Biết về nguồn lực cộng đồng đã giúp đỡ bạn? Chỉnh sửa trang này và bổ sung!_ diff --git a/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/block-proposal/index.md b/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/block-proposal/index.md new file mode 100644 index 00000000000..e7d089c76a1 --- /dev/null +++ b/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/block-proposal/index.md @@ -0,0 +1,69 @@ +--- +title: "Khối đề xuất" +description: "Giải thích cách các khối được đề xuất trong Ethereum bằng chứng cổ phần." +lang: vi +--- + +Các khối là những đơn vị cơ bản của chuỗi khối. Các khối là những đơn vị thông tin riêng biệt được chuyển qua lại giữa các nút, được đồng thuận và được thêm vào cơ sở dữ liệu của mỗi nút. Trang này giải thích cách chúng được tạo ra. + +## Điều kiện tiên quyết {#prerequisites} + +Việc đề xuất khối là một phần của giao thức bằng chứng cổ phần. Để giúp bạn hiểu trang này, chúng tôi khuyên bạn nên đọc về [bằng chứng cổ phần](/developers/docs/consensus-mechanisms/pos/) và [kiến trúc khối](/developers/docs/blocks/). + +## Ai tạo ra các khối? {#who-produces-blocks} + +Các tài khoản trình xác thực đề xuất các khối. Các tài khoản trình xác thực được quản lý bởi các nhà điều hành nút, những người chạy phần mềm trình xác thực như một phần của máy khách thực thi và máy khách đồng thuận của họ và đã ký gửi ít nhất 32 ETH vào hợp đồng ký gửi. Tuy nhiên, mỗi trình xác thực chỉ thỉnh thoảng chịu trách nhiệm đề xuất một khối. Ethereum đo lường thời gian bằng slot và epoch. Mỗi slot dài mười hai giây, và 32 slot (6,4 phút) tạo thành một epoch. Mỗi slot là một cơ hội để thêm một khối mới trên Ethereum. + +### Lựa chọn ngẫu nhiên {#random-selection} + +Một trình xác thực duy nhất được chọn một cách giả ngẫu nhiên để đề xuất một khối trong mỗi slot. Không có cái gọi là sự ngẫu nhiên thực sự trong một chuỗi khối bởi vì nếu mỗi nút tạo ra các số ngẫu nhiên thực sự, chúng sẽ không thể đạt được sự đồng thuận. Thay vào đó, mục đích là làm cho quy trình lựa chọn trình xác thực không thể đoán trước được. Sự ngẫu nhiên được thực hiện trên Ethereum bằng cách sử dụng một thuật toán gọi là RANDAO, thuật toán này trộn một hàm băm từ người đề xuất khối với một hạt giống được cập nhật mỗi khối. Giá trị này được sử dụng để chọn một người xác thực cụ thể từ tổng bộ người xác thực. Việc lựa chọn trình xác thực được ấn định trước hai epoch như một cách để bảo vệ chống lại một số loại thao túng hạt giống nhất định. + +Mặc dù các trình xác thực thêm vào RANDAO trong mỗi slot, giá trị RANDAO toàn cục chỉ được cập nhật một lần mỗi epoch. Để tính toán chỉ số của người đề xuất khối tiếp theo, giá trị RANDAO được trộn với số slot để tạo ra một giá trị duy nhất trong mỗi slot. Xác suất một trình xác thực cá nhân được chọn không đơn giản là `1/N` (với `N` = tổng số trình xác thực đang hoạt động). Thay vào đó, nó được tính trọng số theo số dư ETH hiệu quả của mỗi trình xác thực. Số dư hiệu quả tối đa là 32 ETH (điều này có nghĩa là `số dư < 32 ETH` dẫn đến trọng số thấp hơn so với `số dư == 32 ETH`, nhưng `số dư > 32 ETH` không dẫn đến trọng số cao hơn so với `số dư == 32 ETH`). + +Chỉ một người đề xuất khối được chọn trong mỗi slot. Trong điều kiện bình thường, một người tạo khối duy nhất sẽ tạo và phát hành một khối duy nhất trong slot dành riêng cho họ. Việc tạo hai khối cho cùng một slot là một hành vi có thể bị cắt giảm, thường được gọi là "nhập nhằng". + +## Khối được tạo ra như thế nào? {#how-is-a-block-created} + +Người đề xuất khối dự kiến sẽ phát một khối beacon đã ký, khối này xây dựng trên đỉnh đầu gần đây nhất của chuỗi theo góc nhìn của thuật toán lựa chọn phân nhánh do họ tự chạy cục bộ. Thuật toán lựa chọn phân nhánh áp dụng bất kỳ sự chứng thực nào đang chờ trong hàng đợi còn sót lại từ slot trước, sau đó tìm khối có trọng lượng chứng thực tích lũy lớn nhất trong lịch sử của nó. Khối đó là khối cha của khối mới do người đề xuất tạo ra. + +Người đề xuất khối tạo ra một khối bằng cách thu thập dữ liệu từ cơ sở dữ liệu cục bộ và góc nhìn về chuỗi của riêng nó. Nội dung của khối được hiển thị trong đoạn mã dưới đây: + +```rust +class BeaconBlockBody(Container): + randao_reveal: BLSSignature + eth1_data: Eth1Data + graffiti: Bytes32 + proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS] + attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS] + attestations: List[Attestation, MAX_ATTESTATIONS] + deposits: List[Deposit, MAX_DEPOSITS] + voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS] + sync_aggregate: SyncAggregate + execution_payload: ExecutionPayload +``` + +Trường `randao_reveal` nhận một giá trị ngẫu nhiên có thể xác minh mà người đề xuất khối tạo ra bằng cách ký vào số epoch hiện tại. `eth1_data` là một phiếu bầu cho góc nhìn của người đề xuất khối về hợp đồng ký gửi, bao gồm gốc của cây Merkle ký gửi và tổng số lượng ký gửi cho phép các khoản ký gửi mới được xác minh. `graffiti` là một trường tùy chọn có thể được sử dụng để thêm một thông điệp vào khối. `proposer_slashings` và `attester_slashings` là các trường chứa bằng chứng cho thấy một số trình xác thực nhất định đã thực hiện các hành vi có thể bị cắt giảm theo góc nhìn của người đề xuất về chuỗi. `deposits` là một danh sách các khoản ký gửi của trình xác thực mới mà người đề xuất khối biết, và `voluntary_exits` là một danh sách các trình xác thực muốn thoát mà người đề xuất khối đã nghe nói đến trên mạng gossip của lớp đồng thuận. `sync_aggregate` là một vector cho thấy những trình xác thực nào trước đây đã được chỉ định vào một ủy ban đồng bộ (một tập hợp con các trình xác thực phục vụ dữ liệu máy khách nhẹ) và đã tham gia vào việc ký dữ liệu. + +`execution_payload` cho phép thông tin về các giao dịch được chuyển qua lại giữa máy khách thực thi và máy khách đồng thuận. `execution_payload` là một khối dữ liệu thực thi được lồng vào bên trong một khối beacon. Các trường bên trong `execution_payload` phản ánh cấu trúc khối được nêu trong Sách vàng Ethereum, ngoại trừ việc không có ommer và `prev_randao` tồn tại thay cho `difficulty`. Máy khách thực thi có quyền truy cập vào một nhóm giao dịch cục bộ mà nó đã nghe được trên mạng gossip của riêng mình. Các giao dịch này được thực thi cục bộ để tạo ra một cây trie trạng thái được cập nhật, được gọi là trạng thái sau. Các giao dịch được bao gồm trong `execution_payload` dưới dạng một danh sách được gọi là `transactions` và trạng thái sau được cung cấp trong trường `state-root`. + +Tất cả các dữ liệu này được thu thập trong một khối beacon, được ký và phát đến các máy ngang hàng của người đề xuất khối, những máy này sẽ lan truyền nó đến các máy ngang hàng của họ, v.v. + +Đọc thêm về [cấu trúc của các khối](/developers/docs/blocks). + +## Điều gì xảy ra với khối? {#what-happens-to-blocks} + +Khối được thêm vào cơ sở dữ liệu cục bộ của người đề xuất khối và được phát đến các máy ngang hàng qua mạng gossip của lớp đồng thuận. Khi một trình xác thực nhận được khối, nó sẽ xác minh dữ liệu bên trong đó, bao gồm việc kiểm tra rằng khối đó có khối cha chính xác, tương ứng với slot chính xác, chỉ số người đề xuất là chỉ số được mong đợi, việc tiết lộ RANDAO là hợp lệ và người đề xuất không bị cắt giảm. `execution_payload` được tách ra, và máy khách thực thi của trình xác thực sẽ thực thi lại các giao dịch trong danh sách để kiểm tra sự thay đổi trạng thái được đề xuất. Giả sử khối vượt qua tất cả các kiểm tra này, mỗi trình xác thực sẽ thêm khối đó vào chuỗi chính tắc của riêng mình. Quy trình sau đó bắt đầu lại trong slot tiếp theo. + +## Phần thưởng khối {#block-rewards} + +Người đề xuất khối nhận được thanh toán cho công việc của họ. Có một `base_reward` được tính như một hàm của số lượng trình xác thực đang hoạt động và số dư hiệu quả của chúng. Người đề xuất khối sau đó nhận được một phần của `base_reward` cho mỗi sự chứng thực hợp lệ có trong khối; càng nhiều trình xác thực chứng thực cho khối, phần thưởng của người đề xuất khối càng lớn. Cũng có một phần thưởng cho việc báo cáo các trình xác thực nên bị cắt giảm, bằng `1/512 * số dư hiệu quả` cho mỗi trình xác thực bị cắt giảm. + +[Thông tin thêm về phần thưởng và hình phạt](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) + +## Đọc thêm {#further-reading} + +- [Giới thiệu về các khối](/developers/docs/blocks/) +- [Giới thiệu về Cơ chế bảo chứng cổ phần](/developers/docs/consensus-mechanisms/pos/) +- [Thông số kỹ thuật đồng thuận của Ethereum](https://github.com/ethereum/consensus-specs) +- [Giới thiệu về Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) +- [Nâng cấp Ethereum](https://eth2book.info/) diff --git a/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/faqs/index.md b/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/faqs/index.md new file mode 100644 index 00000000000..64292d2fe07 --- /dev/null +++ b/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/faqs/index.md @@ -0,0 +1,172 @@ +--- +title: "Những câu hỏi thường gặp" +description: "Những câu hỏi thường gặp về bằng chứng cổ phần trên Ethereum." +lang: vi +--- + +## Bằng chứng cổ phần là gì {#what-is-proof-of-stake} + +Proof-of-stake (bằng chứng cố phần) là một dạng thuật toán có thể cung cấp tính bảo mật cho blockchain bằng cách đảm bảo rằng tài sản có giá trị sẽ bị mất đi đối với những kẻ tấn công hành xử không trung thực. Các hệ thống bằng chứng cổ phần yêu cầu một tập hợp các trình xác thực phải ký gửi tài sản, và tài sản này có thể bị tịch thu nếu trình xác thực thực hiện hành vi gian lận có thể chứng minh được. Ethereum sử dụng cơ chế bằng chứng cổ phần này để bảo mật blockchain. + +## Cơ chế bằng chứng cổ phần khác gì so với cơ chế bằng chứng công việc? {#comparison-to-proof-of-work} + +Cả cơ chế bằng chứng công việc và cơ chế bằng chứng cổ phần đều là những cơ chế nhằm ngăn chặn về mặt kinh tế các tác nhân độc hại khỏi việc gây quá tải hoặc gian lận mạng lưới. Trong cả hai trường hợp, các nút tham gia tích cực vào cơ chế đồng thuận sẽ phải đặt một loại tài sản nào đó “vào trong mạng lưới”, và họ sẽ mất nó nếu có hành vi sai trái. + +Trong cơ chế bằng chứng công việc, tài sản này là năng lượng. Nút, được gọi là thợ đào, chạy một thuật toán nhằm tính toán giá trị nhanh hơn bất kỳ nút nào khác. Nút nhanh nhất sẽ có quyền đề xuất một khối lên chuỗi. Để thay đổi lịch sử của chuỗi hoặc chiếm quyền đề xuất khối, một thợ đào sẽ phải sở hữu sức mạnh tính toán khổng lồ đến mức họ luôn giành chiến thắng. Điều này vô cùng tốn kém và khó thực hiện, giúp bảo vệ chuỗi khỏi các cuộc tấn công. Năng lượng cần thiết để “đào” bằng cơ chế bằng chứng công việc là một loại tài sản thực tế mà các thợ đào phải trả. + +Cơ chế bằng chứng cổ phần yêu cầu các nút, được gọi là những người xác thực, phải nộp trực tiếp một tài sản tiền mã hóa vào một hợp đồng thông minh. Nếu một người xác thực hành xử sai trái, số tiền điện tử này có thể bị tiêu hủy vì họ đã “đặt cọc” tài sản trực tiếp vào chuỗi thay vì gián tiếp thông qua việc tiêu thụ năng lượng. + +Cơ chế bằng chứng công việc tiêu tốn rất nhiều năng lượng vì điện năng bị thất thoát trong quá trình khai thác. Cơ chế bằng chứng cổ phần, ngược lại, chỉ yêu cầu một lượng năng lượng rất nhỏ – các trình xác thực Ethereum thậm chí có thể chạy trên những thiết bị công suất thấp như Raspberry Pi. Cơ chế bằng chứng cổ phần của Ethereum được cho là an toàn hơn so với bằng chứng công việc vì chi phí để tấn công cao hơn và hậu quả đối với kẻ tấn công cũng nghiêm trọng hơn. + +So sánh giữa bằng chứng công việc và bằng chứng cổ phần là một chủ đề gây nhiều tranh cãi. [Blog của Vitalik Buterin](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work) và cuộc tranh luận giữa Justin Drake và Lyn Alden đã tóm tắt rõ ràng các luận điểm. + + + +## Cơ chế bằng chứng cổ phần có tiết kiệm năng lượng không? {#is-pos-energy-efficient} + +Đúng vậy. Các nút trong một mạng lưới bằng chứng cổ phần chỉ sử dụng một lượng năng lượng rất nhỏ. Một nghiên cứu của bên thứ ba kết luận rằng toàn bộ mạng Ethereum sử dụng cơ chế bằng chứng cổ phần chỉ tiêu thụ khoảng 0,0026 TWh mỗi năm – thấp hơn khoảng 13,000 lần so với việc chơi game tại Mỹ. + +[Tìm hiểu thêm về mức tiêu thụ năng lượng của Ethereum](/energy-consumption/). + +## Cơ chế bằng chứng cổ phần có an toàn không? {#is-pos-secure} + +Cơ chế bằng chứng cổ phần của Ethereum rất an toàn. Cơ chế này đã được nghiên cứu, phát triển và kiểm thử nghiêm ngặt trong hơn tám năm trước khi chính thức đưa vào hoạt động. Các bảo đảm về mặt an ninh khác với những blockchain sử dụng cơ chế bằng chứng công việc. Trong cơ chế bằng chứng cổ phần, các trình xác thực độc hại có thể bị trừng phạt trực tiếp (bị “cắt giảm”) và bị loại khỏi tập hợp xác thực, đồng thời mất đi một lượng lớn ETH. Trong cơ chế bằng chứng công việc, một kẻ tấn công có thể liên tục lặp lại cuộc tấn công miễn là họ có đủ sức mạnh băm. Việc thực hiện các cuộc tấn công tương tự trên Ethereum sử dụng cơ chế bằng chứng cổ phần tốn kém hơn nhiều so với bằng chứng công việc. Để ảnh hưởng đến tính sống còn của chuỗi, cần ít nhất 33% tổng số ETH đã đặt cọc trong mạng lưới (ngoại trừ các trường hợp tấn công cực kỳ tinh vi với khả năng thành công cực thấp). Để kiểm soát nội dung của các khối trong tương lai, cần ít nhất 51% tổng số ETH đã đặt cọc, và để viết lại lịch sử, cần hơn 66% tổng số tài sản đặt cọc. Giao thức Ethereum sẽ tiêu hủy những tài sản này trong các kịch bản tấn công 33% hoặc 51%, và bằng sự đồng thuận xã hội trong kịch bản tấn công 66%. + +- [Tìm hiểu thêm về cách bảo vệ bằng chứng cổ phần Ethereum khỏi những kẻ tấn công](/developers/docs/consensus-mechanisms/pos/attack-and-defense) +- [Tìm hiểu thêm về thiết kế bằng chứng cổ phần](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) + +## Cơ chế bằng chứng cổ phần có làm cho Ethereum rẻ hơn không? {#does-pos-make-ethereum-cheaper} + +Không. Chi phí để gửi một giao dịch (phí gas) được quyết định bởi một thị trường phí biến động, tăng lên khi nhu cầu mạng cao hơn. Cơ chế đồng thuận không trực tiếp ảnh hưởng đến điều này. + +[Tìm hiểu thêm về gas](/developers/docs/gas). + +## Nút, khách hàng và trình xác thực là gì? {#what-are-nodes-clients-and-validators} + +Nút là các máy tính được kết nối với mạng Ethereum. Khách hàng là phần mềm mà chúng chạy để biến máy tính thành một nút. Có hai loại khách hàng: khách hàng thực thi và khách hàng đồng thuận. Cả hai đều cần thiết để tạo ra một nút. Trình xác thực là một phần bổ sung tùy chọn cho khách hàng đồng thuận, cho phép nút tham gia vào cơ chế đồng thuận bằng chứng cổ phần. Điều này có nghĩa là tạo và đề xuất các khối khi được chọn, đồng thời chứng thực các khối mà họ nhận được trên mạng lưới. Để vận hành một trình xác thực, người vận hành nút phải gửi ký quỹ 32 ETH vào hợp đồng ký gửi. + +- [Tìm hiểu thêm về các nút và máy khách](/developers/docs/nodes-and-clients) +- [Tìm hiểu thêm về đặt cọc](/staking) + +## Bằng chứng cổ phần có phải ý tưởng mới không? {#is-pos-new} + +Không. Một người dùng trên BitcoinTalk [đã đề xuất ý tưởng cơ bản về bằng chứng cổ phần](https://bitcointalk.org/index.php?topic=27787.0) như một bản nâng cấp cho Bitcoin vào năm 2011. Phải tới mười một năm sau mới sẵn sàng để tích hợp vào mạng chính Ethereum. Một số chuỗi khác đã triển khai bằng chứng cổ phần sớm hơn Ethereum, nhưng không phải cơ chế cụ thể của Ethereum (được gọi là Gasper). + +## Bằng chứng cổ phần của Ethereum có gì đặc biệt? {#why-is-ethereum-pos-special} + +Cơ chế bằng chứng cổ phần của Ethereum là độc nhất trong thiết kế của nó. Đây không phải là cơ chế bằng chứng cổ phần đầu tiên được thiết kế và triển khai, nhưng nó là cơ chế mạnh mẽ nhất. Cơ chế bằng chứng cổ phần được gọi là "Casper". Casper xác định cách người xác thực được chọn để đề xuất các khối, cách thức và thời điểm thực hiện các chứng thực, cách đếm các chứng thực, các phần thưởng và hình phạt dành cho người xác thực, các điều kiện xử phạt, các cơ chế an toàn như rò rỉ do không hoạt động, và các điều kiện cho "tính kết luận cuối cùng". Tính kết luận cuối cùng là điều kiện để một khối được coi là một phần vĩnh viễn của chuỗi chính tắc, nó phải được bỏ phiếu bởi ít nhất 66% tổng số ETH đã đặt cọc trên mạng. Các nhà nghiên cứu đã phát triển Casper dành riêng cho Ethereum, và Ethereum là chuỗi khối đầu tiên và duy nhất đã triển khai nó. + +Ngoài Casper, bằng chứng cổ phần của Ethereum sử dụng một thuật toán lựa chọn phân nhánh được gọi là LMD-GHOST. Điều này là cần thiết trong trường hợp phát sinh tình huống có hai khối tồn tại trong cùng một slot. Điều này tạo ra hai phân nhánh của chuỗi khối. LMD-GHOST chọn phân nhánh có "trọng số" chứng thực lớn nhất. Trọng số là số lượng các chứng thực được tính theo số dư hiệu lực của những người xác thực. LMD-GHOST là độc nhất của Ethereum. + +Sự kết hợp giữa Casper và LMD_GHOST được gọi là Gasper. + +[Tìm hiểu thêm về Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) + +## Xử phạt là gì? {#what-is-slashing} + +Xử phạt là thuật ngữ chỉ việc phá hủy một phần cổ phần của người xác thực và loại bỏ người xác thực đó khỏi mạng. Số ETH bị mất trong một lần xử phạt sẽ thay đổi theo số lượng người xác thực bị xử phạt - điều này có nghĩa là những người xác thực thông đồng sẽ bị trừng phạt nặng hơn so với các cá nhân. + +[Tìm hiểu thêm về xử phạt](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties#slashing) + +## Tại sao người xác thực cần 32 ETH? {#why-32-eth} + +Người xác thực phải đặt cọc ETH để họ có thứ để mất nếu họ có hành vi sai trái. Lý do tại sao họ phải đặt cọc cụ thể 32 ETH là để cho phép các nút chạy trên phần cứng khiêm tốn. Nếu số ETH tối thiểu cho mỗi người xác thực thấp hơn, thì số lượng người xác thực và do đó số lượng thông điệp phải được xử lý trong mỗi slot sẽ tăng lên, có nghĩa là cần có phần cứng mạnh hơn để chạy một nút. + +## Người xác thực được chọn như thế nào? {#how-are-validators-selected} + +Một người xác thực duy nhất được chọn một cách ngẫu nhiên giả để đề xuất một khối trong mỗi slot bằng cách sử dụng một thuật toán gọi là RANDAO, thuật toán này trộn một hàm băm từ người đề xuất khối với một hạt giống được cập nhật mỗi khối. Giá trị này được sử dụng để chọn một người xác thực cụ thể từ tổng bộ người xác thực. Việc lựa chọn người xác thực được cố định trước hai epoch. + +[Tìm hiểu thêm về việc lựa chọn người xác thực](/developers/docs/consensus-mechanisms/pos/block-proposal) + +## Stake grinding là gì? {#what-is-stake-grinding} + +Stake grinding là một loại tấn công vào các mạng bằng chứng cổ phần, trong đó kẻ tấn công cố gắng làm sai lệch thuật toán lựa chọn người xác thực để ưu tiên cho những người xác thực của chính họ. Các cuộc tấn công stake grinding vào RANDAO yêu cầu khoảng một nửa tổng số ETH đã đặt cọc. + +[Tìm hiểu thêm về stake grinding](https://eth2book.info/altair/part2/building_blocks/randomness/#randao-biasability) + +## Xử phạt xã hội là gì? {#what-is-social-slashing} + +Xử phạt xã hội là khả năng cộng đồng phối hợp để tạo một phân nhánh của chuỗi khối nhằm đối phó với một cuộc tấn công. Nó cho phép cộng đồng phục hồi sau khi một kẻ tấn công hoàn tất một chuỗi không trung thực. Xử phạt xã hội cũng có thể được sử dụng để chống lại các cuộc tấn công kiểm duyệt. + +- [Tìm hiểu thêm về xử phạt xã hội](https://ercwl.medium.com/the-case-for-social-slashing-59277ff4d9c7) +- [Vitalik Buterin nói về xử phạt xã hội](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) + +## Tôi có bị xử phạt không? {#will-i-get-slashed} + +Là một người xác thực, rất khó để bị xử phạt trừ khi bạn cố tình tham gia vào hành vi độc hại. Xử phạt chỉ được thực hiện trong các tình huống rất cụ thể, khi người xác thực đề xuất nhiều khối cho cùng một slot hoặc tự mâu thuẫn với các chứng thực của họ - những điều này rất khó xảy ra một cách vô tình. + +[Tìm hiểu thêm về các điều kiện xử phạt](https://eth2book.info/altair/part2/incentives/slashing) + +## Vấn đề nothing-at-stake là gì? {#what-is-nothing-at-stake-problem} + +Vấn đề nothing-at-stake là một vấn đề về mặt khái niệm với một số cơ chế bằng chứng cổ phần, nơi chỉ có phần thưởng mà không có hình phạt. Nếu không có gì để mất, một người xác thực thực dụng sẽ vui vẻ chứng thực cho bất kỳ, hoặc thậm chí nhiều, phân nhánh của chuỗi khối, vì điều này làm tăng phần thưởng của họ. Ethereum giải quyết vấn đề này bằng cách sử dụng các điều kiện về tính kết luận cuối cùng và xử phạt để đảm bảo một chuỗi chính tắc duy nhất. + +[Tìm hiểu thêm về vấn đề nothing-at-stake](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed) + +## Thuật toán lựa chọn nhánh là gì? {#what-is-a-fork-choice-algorithm} + +Thuật toán lựa chọn nhánh thực hiện các quy tắc để xác định chuỗi nào là chuỗi chuẩn. Trong điều kiện tối ưu, không cần đến quy tắc lựa chọn nhánh vì mỗi khe thời gian chỉ có một người đề xuất khối và một khối để lựa chọn. Tuy nhiên, đôi khi có thể xuất hiện nhiều khối cho cùng một khe thời gian hoặc thông tin đến chậm, dẫn đến nhiều lựa chọn khác nhau về cách các khối gần đầu chuỗi được sắp xếp. Trong những trường hợp này, tất cả các khách hàng đều phải thực thi một số quy tắc giống nhau để đảm bảo rằng họ đều chọn đúng chuỗi khối. Thuật toán lựa chọn nhánh mã hóa những quy tắc này. + +Thuật toán lựa chọn nhánh của Ethereum được gọi là LMD-GHOST. Nó chọn nhánh có trọng số xác thực lớn nhất, tức là nhánh mà phần ETH đặt cọc nhiều nhất đã bỏ phiếu. + +[Tìm hiểu thêm về LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper/#fork-choice) + +## Tính cuối cùng trong cơ chế bằng chứng cổ phần là gì? {#what-is-finality} + +Tính cuối cùng trong bằng chứng cổ phần là sự đảm bảo rằng một khối nhất định sẽ trở thành một phần vĩnh viễn của chuỗi chính và không thể bị đảo ngược trừ khi xảy ra lỗi đồng thuận, trong đó một kẻ tấn công phải đốt 33% tổng số ether đã đặt cọc. Đây là “tính cuối cùng kinh tế-mã hóa”, trái ngược với “tính cuối cùng xác suất” vốn liên quan đến các blockchain dùng bằng chứng công việc. Trong tính cuối cùng xác suất, không có trạng thái nào rõ ràng là đã hoàn tất hay chưa hoàn tất đối với các khối – nó chỉ đơn giản trở nên ít có khả năng hơn rằng một khối có thể bị loại bỏ khỏi chuỗi khi nó ngày càng cũ đi, và người dùng sẽ tự quyết định khi nào họ đủ tin tưởng rằng một khối là “an toàn”. Với tính cuối cùng kinh tế-mã hóa, các cặp khối điểm kiểm tra phải được ít nhất 66% lượng ether đặt cọc bỏ phiếu tán thành. Nếu điều kiện này được đáp ứng, các khối nằm giữa những điểm kiểm tra đó sẽ được xác nhận rõ ràng là “hoàn tất”. + +[Tìm hiểu thêm về tính kết luận cuối cùng](/developers/docs/consensus-mechanisms/pos/#finality) + +## Tính “chủ quan yếu” là gì? {#what-is-weak-subjectivity} + +Chủ quan yếu là một đặc điểm của các mạng lưới bằng chứng cổ phần, trong đó thông tin xã hội được sử dụng để xác nhận trạng thái hiện tại của blockchain. Các nút mới hoặc các nút tham gia lại mạng sau một thời gian ngoại tuyến dài có thể được cung cấp một điểm kiểm tra gần đây để nút đó có thể ngay lập tức nhận biết liệu mình đang ở trên chuỗi đúng hay không. Những trạng thái này được gọi là “các điểm kiểm tra của chủ quan yếu” và có thể được lấy từ những người vận hành nút khác ngoài kênh chính, hoặc từ các trình khám phá khối, hoặc từ một số điểm truy cập công khai. + +[Tìm hiểu thêm về tính chủ quan yếu](/developers/docs/consensus-mechanisms/pos/weak-subjectivity) + +## Cơ chế bằng chứng cổ phần có chống kiểm duyệt không? {#is-pos-censorship-resistant} + +Khả năng chống kiểm duyệt hiện tại vẫn khó chứng minh. Tuy nhiên, không giống như bằng chứng công việc, bằng chứng cổ phần cung cấp tùy chọn phối hợp cắt giảm để trừng phạt các trình xác thực có hành vi kiểm duyệt. Sắp tới sẽ có những thay đổi trong giao thức nhằm tách biệt những người xây dựng khối khỏi những người đề xuất khối và áp dụng danh sách các giao dịch mà người xây dựng phải đưa vào mỗi khối. Đề xuất này được gọi là “tách biệt người xây dựng và người đề xuất”, và nó giúp ngăn các trình xác thực kiểm duyệt giao dịch. + +[Tìm hiểu thêm về việc tách biệt người đề xuất-người xây dựng](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Original-basic-scheme) + +## Hệ thống bằng chứng cổ phần của Ethereum có thể bị tấn công 51% không? {#pos-51-attack} + +Đúng vậy. Bằng chứng cổ phần dễ bị tấn công 51%, giống như bằng chứng công việc. Thay vì kẻ tấn công cần 51% sức mạnh băm của mạng, thì trong cơ chế này kẻ tấn công cần 51% tổng số ETH đã đặt cọc. Một kẻ tấn công tích lũy được 51% tổng số tài sản đặt cọc sẽ kiểm soát thuật toán lựa chọn nhánh. Điều này cho phép kẻ tấn công kiểm duyệt một số giao dịch, thực hiện sắp xếp lại ngắn hạn và trích xuất MEV bằng cách sắp xếp lại các khối theo hướng có lợi cho họ. + +[Tìm hiểu thêm về các cuộc tấn công vào bằng chứng cổ phần](/developers/docs/consensus-mechanisms/pos/attack-and-defense) + +## Sự phối hợp xã hội là gì, và tại sao nó cần thiết? {#what-is-social-coordination} + +Sự phối hợp xã hội là tuyến phòng thủ cuối cùng của Ethereum, cho phép một chuỗi trung thực có thể phục hồi sau một cuộc tấn công mà trong đó các khối gian lận đã được hoàn tất. Trong trường hợp này, cộng đồng Ethereum sẽ phải phối hợp “ngoài kênh chính” và đồng ý sử dụng một nhánh thiểu số trung thực, đồng thời cắt giảm các trình xác thực của kẻ tấn công trong quá trình đó. Điều này cũng đòi hỏi các ứng dụng và sàn giao dịch phải công nhận nhánh trung thực. + +[Đọc thêm về sự phối hợp xã hội](/developers/docs/consensus-mechanisms/pos/attack-and-defense#people-the-last-line-of-defense) + +## Người giàu có giàu thêm trong cơ chế bằng chứng cổ phần không? {#do-rich-get-richer} + +Càng có nhiều ETH để đặt cọc, một người càng có thể vận hành nhiều trình xác thực hơn và nhận được nhiều phần thưởng hơn. Phần thưởng tăng tuyến tính theo lượng ETH đã đặt cọc, và mọi người đều nhận được tỷ lệ lợi nhuận phần trăm như nhau. Cơ chế bằng chứng công việc làm người giàu trở nên giàu hơn nhiều so với cơ chế bằng chứng cổ phần, bởi vì những thợ đào giàu hơn có thể đầu tư vào phần cứng mạnh mẽ hơn. + +## Cơ chế bằng chứng cổ phần có tập trung hóa hơn bằng chứng công việc không? {#is-pos-decentralized} + +Không, bằng chứng công việc có xu hướng tập trung hóa vì chi phí khai thác tăng lên và loại bỏ dần các cá nhân, sau đó loại bỏ cả các công ty nhỏ, và cứ thế tiếp diễn. Vấn đề hiện tại của bằng chứng cổ phần là ảnh hưởng của các sản phẩm phái sinh đặt cọc thanh khoản (LSDs). Đây là các token đại diện cho ETH đã được đặt cọc bởi một nhà cung cấp nào đó, và mọi người có thể hoán đổi chúng trên các thị trường thứ cấp mà không cần rút ETH ra. LSDs cho phép người dùng đặt cọc với ít hơn 32 ETH, nhưng đồng thời cũng tạo ra rủi ro tập trung hóa nếu một vài tổ chức lớn có thể kiểm soát phần lớn lượng tài sản đặt cọc. Đây là lý do tại sao [đặt cọc một mình](/staking/solo) là lựa chọn tốt nhất cho Ethereum. + +[Tìm hiểu thêm về việc tập trung hóa cổ phần trong LSD](https://notes.ethereum.org/@djrtwo/risks-of-lsd) + +## Tại sao tôi chỉ có thể ký gửi ETH? {#why-can-i-only-stake-eth} + +ETH là tiền tệ nội địa của Ethereum. Việc có một loại tiền tệ duy nhất mà trong đó tất cả các cổ phần được định giá là điều cần thiết, cho cả việc hạch toán số dư hiệu lực để tính trọng số phiếu bầu và cho mục đích bảo mật. Bản thân ETH là một thành phần cơ bản của Ethereum chứ không phải là một hợp đồng thông minh. Việc kết hợp các loại tiền tệ khác sẽ làm tăng đáng kể độ phức tạp và giảm tính bảo mật của việc đặt cọc. + +## Ethereum có phải chuỗi khối duy nhất dùng bằng chứng cổ phần? {#is-ethereum-the-only-pos-blockchain} + +Không, có vài chuỗi khối bằng chứng cổ phần khác. Không có cái nào giống Ethereum. cơ chế bằng chứng cổ phần của Ethereum là độc nhất. + +## Sự kiện Hợp nhất là gì? {#what-is-the-merge} + +Sự kiện Hợp nhất là khoảnh khắc Ethereum tắt cơ chế đồng thuận bằng chứng công việc của mình và bật cơ chế đồng thuận bằng chứng cổ phẩn. Sự kiện Hợp nhất đã diễn ra vào 15 tháng 9 năm 2022. + +[Tìm hiểu thêm về The Merge](/roadmap/merge) + +## Tính hoạt động và tính an toàn là gì? {#what-are-liveness-and-safety} + +Tính hoạt động và tính an toàn là hai mối quan tâm bảo mật cơ bản đối với một chuỗi khối. Tính hoạt động là sự sẵn có của một chuỗi đang hoàn tất. Nếu chuỗi ngừng hoàn tất hoặc người dùng không thể truy cập dễ dàng, đó là những thất bại về tính hoạt động. Chi phí truy cập cực kỳ cao cũng có thể được coi là một thất bại về tính hoạt động. Tính an toàn đề cập đến mức độ khó khăn để tấn công chuỗi - tức là hoàn tất các điểm kiểm tra xung đột. + +[Đọc thêm trong tài liệu về Casper](https://arxiv.org/pdf/1710.09437.pdf) diff --git a/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/gasper/index.md b/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/gasper/index.md new file mode 100644 index 00000000000..7ff9bbedabe --- /dev/null +++ b/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/gasper/index.md @@ -0,0 +1,52 @@ +--- +title: Gasper +description: "Giải thích về cơ chế bằng chứng cổ phần Gasper." +lang: vi +--- + +Gasper là sự kết hợp của Casper the Friendly Finality Gadget (Casper-FFG) và thuật toán lựa chọn phân nhánh LMD-GHOST. Các thành phần này cùng nhau tạo thành cơ chế đồng thuận bảo mật cho Ethereum bằng chứng cổ phần. Casper là cơ chế nâng cấp các khối nhất định thành "hoàn tất" để những người mới tham gia vào mạng có thể tin tưởng rằng họ đang đồng bộ hóa chuỗi chính tắc. Thuật toán lựa chọn phân nhánh sử dụng các phiếu bầu tích lũy để đảm bảo rằng các nút có thể dễ dàng chọn đúng khi các phân nhánh phát sinh trong chuỗi khối. + +**Lưu ý** rằng định nghĩa ban đầu của Casper-FFG đã được cập nhật một chút để đưa vào Gasper. Trên trang này, chúng tôi xem xét phiên bản đã cập nhật. + +## Lời mở đầu + +Để hiểu tài liệu này, cần phải đọc trang giới thiệu về [bằng chứng cổ phần](/developers/docs/consensus-mechanisms/pos/). + +## Vai trò của Gasper {#role-of-gasper} + +Gasper nằm trên một chuỗi khối bằng chứng cổ phần, nơi các nút cung cấp ether làm tiền ký quỹ bảo mật có thể bị hủy nếu chúng lười biếng hoặc không trung thực trong việc đề xuất hoặc xác thực các khối. Gasper là cơ chế xác định cách các trình xác thực được thưởng và bị phạt, quyết định chấp nhận và từ chối khối nào và xây dựng trên phân nhánh nào của chuỗi khối. + +## Tính kết luận cuối cùng là gì? {#what-is-finality} + +Tính kết luận cuối cùng là một thuộc tính của các khối nhất định có nghĩa là chúng không thể bị hoàn nguyên trừ khi đã có một lỗi đồng thuận nghiêm trọng và một kẻ tấn công đã phá hủy ít nhất 1/3 tổng số ether đã đặt cọc. Các khối đã hoàn tất có thể được coi là thông tin mà chuỗi khối chắc chắn. Một khối phải trải qua một quy trình nâng cấp hai bước để được hoàn tất: + +1. Hai phần ba tổng số ether đã đặt cọc phải đã bỏ phiếu ủng hộ việc đưa khối đó vào chuỗi chính tắc. Điều kiện này nâng cấp khối thành "hợp lý". Các khối hợp lý không có khả năng bị hoàn nguyên, nhưng có thể bị trong một số điều kiện nhất định. +2. Khi một khối khác được hợp lý hóa trên một khối đã hợp lý, nó được nâng cấp thành "hoàn tất". Việc hoàn tất một khối là một cam kết đưa khối đó vào chuỗi chính tắc. Nó không thể bị hoàn nguyên trừ khi một kẻ tấn công phá hủy hàng triệu ether (hàng tỷ USD). + +Những nâng cấp khối này không xảy ra trong mọi slot. Thay vào đó, chỉ các khối ranh giới tham số epoch mới có thể được hợp lý hóa và hoàn tất. Các khối này được gọi là "điểm kiểm tra". Việc nâng cấp xem xét các cặp điểm kiểm tra. Một "liên kết siêu đa số" phải tồn tại giữa hai điểm kiểm tra liên tiếp (tức là, hai phần ba tổng số ether đã đặt cọc bỏ phiếu rằng điểm kiểm tra B là hậu duệ chính xác của điểm kiểm tra A) để nâng cấp điểm kiểm tra cũ hơn thành hoàn tất và khối gần đây hơn thành hợp lý. + +Bởi vì tính kết luận cuối cùng yêu cầu sự đồng ý của hai phần ba rằng một khối là chính tắc, một kẻ tấn công không thể tạo ra một chuỗi đã hoàn tất thay thế mà không: + +1. Sở hữu hoặc thao túng hai phần ba tổng số ether đã đặt cọc. +2. Phá hủy ít nhất một phần ba tổng số ether đã đặt cọc. + +Điều kiện đầu tiên phát sinh vì cần có hai phần ba số ether đã đặt cọc để hoàn tất một chuỗi. Điều kiện thứ hai phát sinh bởi vì nếu hai phần ba tổng số cổ phần đã bỏ phiếu ủng hộ cả hai phân nhánh, thì một phần ba phải đã bỏ phiếu cho cả hai. Bỏ phiếu hai lần là một điều kiện phạt cắt giảm sẽ bị trừng phạt tối đa, và một phần ba tổng số cổ phần sẽ bị phá hủy. Kể từ tháng 5 năm 2022, điều này yêu cầu một kẻ tấn công phải đốt khoảng 10 tỷ đô la giá trị ether. Thuật toán hợp lý hóa và hoàn tất các khối trong Gasper là một dạng sửa đổi một chút của [Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437.pdf). + +### Ưu đãi và Phạt cắt giảm {#incentives-and-slashing} + +Các trình xác thực được thưởng vì đã đề xuất và xác thực các khối một cách trung thực. Ether được thưởng và được thêm vào cổ phần của họ. Mặt khác, các trình xác thực vắng mặt và không hành động khi được yêu cầu sẽ bỏ lỡ những phần thưởng này và đôi khi mất một phần nhỏ cổ phần hiện có của họ. Tuy nhiên, các hình phạt cho việc ngoại tuyến là nhỏ và, trong hầu hết các trường hợp, tương đương với chi phí cơ hội của việc bỏ lỡ phần thưởng. Tuy nhiên, một số hành động của trình xác thực rất khó thực hiện một cách vô tình và biểu thị một số ý định độc hại, chẳng hạn như đề xuất nhiều khối cho cùng một slot, chứng thực cho nhiều khối cho cùng một slot, hoặc mâu thuẫn với các phiếu bầu điểm kiểm tra trước đó. Đây là những hành vi "có thể bị phạt cắt giảm" bị phạt nặng hơn—phạt cắt giảm dẫn đến một phần cổ phần của trình xác thực bị phá hủy và trình xác thực bị loại khỏi mạng lưới các trình xác thực. Quá trình này mất 36 ngày. Vào ngày 1, có một hình phạt ban đầu lên đến 1 ETH. Sau đó, ether của trình xác thực bị phạt cắt giảm sẽ từ từ cạn kiệt trong suốt thời gian thoát, nhưng vào Ngày 18, họ nhận được một "hình phạt tương quan", hình phạt này lớn hơn khi có nhiều trình xác thực bị phạt cắt giảm cùng lúc. Hình phạt tối đa là toàn bộ cổ phần. Những phần thưởng và hình phạt này được thiết kế để khuyến khích các trình xác thực trung thực và ngăn cản các cuộc tấn công vào mạng. + +### Rò rỉ do không hoạt động {#inactivity-leak} + +Cũng như bảo mật, Gasper cũng cung cấp "tính sống động hợp lý". Đây là điều kiện mà miễn là hai phần ba tổng số ether đã đặt cọc đang bỏ phiếu một cách trung thực và tuân theo giao thức, chuỗi sẽ có thể hoàn tất bất kể bất kỳ hoạt động nào khác (chẳng hạn như các cuộc tấn công, vấn đề về độ trễ hoặc phạt cắt giảm). Nói cách khác, một phần ba tổng số ether đã đặt cọc phải bị xâm phạm bằng cách nào đó để ngăn chuỗi hoàn tất. Trong Gasper, có một tuyến phòng thủ bổ sung chống lại lỗi về tính sống động, được gọi là "rò rỉ do không hoạt động". Cơ chế này được kích hoạt khi chuỗi không thể hoàn tất trong hơn bốn tham số epoch. Các trình xác thực không tích cực chứng thực cho chuỗi đa số sẽ bị rút dần cổ phần của họ cho đến khi phe đa số giành lại được hai phần ba tổng số cổ phần, đảm bảo rằng các lỗi về tính sống động chỉ là tạm thời. + +### Lựa chọn phân nhánh {#fork-choice} + +Định nghĩa ban đầu của Casper-FFG bao gồm một thuật toán lựa chọn phân nhánh áp đặt quy tắc: `theo chuỗi chứa điểm kiểm tra hợp lý có độ cao lớn nhất` trong đó độ cao được định nghĩa là khoảng cách lớn nhất từ khối khởi nguyên. Trong Gasper, quy tắc lựa chọn phân nhánh ban đầu không còn được dùng nữa thay vào đó là một thuật toán phức tạp hơn có tên là LMD-GHOST. Điều quan trọng là phải nhận ra rằng trong điều kiện bình thường, quy tắc lựa chọn phân nhánh là không cần thiết - có một người đề xuất khối duy nhất cho mỗi slot, và các trình xác thực trung thực sẽ chứng thực cho nó. Chỉ trong trường hợp mạng không đồng bộ lớn hoặc khi một người đề xuất khối không trung thực đã đưa ra thông tin không nhất quán thì mới cần đến thuật toán lựa chọn phân nhánh. Tuy nhiên, khi những trường hợp đó phát sinh, thuật toán lựa chọn phân nhánh là một cơ chế phòng thủ quan trọng để bảo mật chuỗi chính xác. + +LMD-GHOST là viết tắt của "cây con quan sát được nặng nhất tham lam theo thông điệp mới nhất". Đây là một cách định nghĩa đầy thuật ngữ cho một thuật toán lựa chọn phân nhánh có trọng số chứng thực tích lũy lớn nhất làm phân nhánh chính tắc (cây con nặng nhất tham lam) và nếu nhận được nhiều thông điệp từ một trình xác thực, thì chỉ thông điệp mới nhất được xem xét (dựa trên thông điệp mới nhất). Trước khi thêm khối nặng nhất vào chuỗi chính tắc của mình, mọi trình xác thực đều đánh giá từng khối bằng quy tắc này. + +## Đọc thêm {#further-reading} + +- [Gasper: Kết hợp GHOST và Casper](https://arxiv.org/pdf/2003.03052.pdf) +- [Casper the Friendly Finality Gadget](https://arxiv.org/pdf/1710.09437.pdf) diff --git a/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/index.md b/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/index.md new file mode 100644 index 00000000000..3259768bf88 --- /dev/null +++ b/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/index.md @@ -0,0 +1,99 @@ +--- +title: "Bằng chứng cổ phần (PoS)" +description: "Giải thích về giao thức đồng thuận bằng chứng cổ phần và vai trò của nó trong Ethereum." +lang: vi +--- + +Bằng chứng cổ phần (PoS) là nền tảng cho [cơ chế đồng thuận](/developers/docs/consensus-mechanisms/) của Ethereum. Ethereum đã chuyển sang cơ chế bằng chứng cổ phần vào năm 2022 vì nó an toàn hơn, ít tốn năng lượng hơn và tốt hơn cho việc triển khai các giải pháp mở rộng quy mô mới so với kiến trúc [bằng chứng công việc](/developers/docs/consensus-mechanisms/pow) trước đây. + +## Điều kiện tiên quyết {#prerequisites} + +Để hiểu rõ hơn về trang này, chúng tôi khuyên bạn nên đọc trước về [các cơ chế đồng thuận](/developers/docs/consensus-mechanisms/). + +## Proof-of-stake (bằng chứng cổ phần - PoS) là gì? {#what-is-pos} + +Bằng chứng cổ phần là cách để chứng minh rằng các Validators đã bỏ thứ gì đó có giá trị vào bên trong mạng lưới, thứ có thể bị phá huỷ nếu họ hành động không trung thực. Trong bằng chứng cổ phần của Ethereum, người xác thực sẽ đặt cọc vốn dưới dạng ETH vào hợp đồng thông minh trên Ethereum. Sau đó, người xác thực có trách nhiệm kiểm tra xem các khối mới được truyền qua mạng có hợp lệ hay không và đôi khi tự tạo và truyền các khối mới. Nếu họ cố gắng lừa đảo mạng (ví dụ bằng cách đề xuất nhiều khối khi họ chỉ nên gửi một khối hoặc gửi các chứng nhận xung đột), một số hoặc toàn bộ ETH họ đặt cọc có thể bị phá hủy. + +## Người xác thực {#validators} + +Để tham gia với tư cách là người xác thực, người dùng phải gửi 32 ETH vào hợp đồng gửi tiền và chạy ba phần mềm riêng biệt: ứng dụng thực hiện, ứng dụng đồng thuận và ứng dụng xác thực. Khi gửi ETH, người dùng sẽ tham gia vào hàng đợi kích hoạt để giới hạn số lượng người xác thực mới tham gia mạng. Sau khi được kích hoạt, người xác thực sẽ nhận được các khối mới từ những người ngang hàng trên mạng Ethereum. Các giao dịch được chuyển giao trong khối sẽ được thực hiện lại để kiểm tra xem những thay đổi được đề xuất đối với trạng thái của Ethereum có hợp lệ hay không và chữ ký khối sẽ được kiểm tra. Sau đó, người xác thực sẽ gửi một phiếu bầu (gọi là chứng thực) ủng hộ khối đó trên toàn mạng. + +Trong khi theo bằng chứng công việc, thời gian của các khối được xác định bởi độ khó khai thác thì theo bằng chứng cổ phần, nhịp độ được cố định. Thời gian trong bằng chứng cổ phần Ethereum được chia thành các slot (12 giây) và tham số epoch (32 slot). Một người xác thực được chọn ngẫu nhiên để trở thành người đề xuất khối trong mỗi vị trí. Người xác thực này chịu trách nhiệm tạo một khối mới và gửi nó đến các nút khác trên mạng. Ngoài ra, ở mỗi vị trí, một ủy ban gồm những người xác thực được chọn ngẫu nhiên, phiếu bầu của họ được sử dụng để xác định tính hợp lệ của khối được đề xuất. Chia người xác thực thành các ủy ban là rất quan trọng để quản lý được tải mạng. Các ủy ban phân chia nhóm người xác thực sao cho mọi người xác thực đang hoạt động đều chứng thực trong mọi tham số epoch, nhưng không phải trong mọi slot. + +## Cách một Giao dịch được Thực thi trong Ethereum PoS {#transaction-execution-ethereum-pos} + +Phần sau đây cung cấp lời giải thích toàn diện về cách thực hiện giao dịch trong cơ chế bằng chứng cổ phần của Ethereum. + +1. Người dùng tạo và ký một [giao dịch](/developers/docs/transactions/) bằng khóa riêng tư của họ. Tác vụ này thường được xử lý bởi một ví hoặc một thư viện như [ethers.js](https://docs.ethers.org/v6/), [web3js](https://docs.web3js.org/), [web3py](https://web3py.readthedocs.io/en/v5/), v.v. nhưng thực chất người dùng đang gửi yêu cầu tới một nút bằng [API JSON-RPC](/developers/docs/apis/json-rpc/) của Ethereum. Người dùng xác định số tiền gas mà họ sẵn sàng trả làm tiền boa cho người xác thực để khuyến khích họ đưa giao dịch vào một khối. [Phí ưu tiên](/developers/docs/gas/#priority-fee) được trả cho trình xác thực trong khi [phí cơ bản](/developers/docs/gas/#base-fee) bị đốt. +2. Giao dịch được gửi đến một [máy khách thực thi](/developers/docs/nodes-and-clients/#execution-client) của Ethereum để xác minh tính hợp lệ của nó. Điều này có nghĩa là phải đảm bảo rằng người gửi có đủ ETH để thực hiện giao dịch và họ đã ký giao dịch bằng đúng khóa. +3. Nếu giao dịch hợp lệ, ứng dụng thực hiện sẽ thêm giao dịch đó vào khu vực chờ cục bộ (danh sách các giao dịch đang chờ xử lý) và cũng phát nó đến các nút khác qua mạng gossip của lớp thực hiện. Khi các nút khác biết về giao dịch, chúng cũng sẽ thêm giao dịch đó vào khu vực chờ cục bộ của chúng. Người dùng nâng cao có thể không phát giao dịch của họ mà thay vào đó chuyển tiếp nó đến các trình tạo khối chuyên dụng như [Flashbots Auction](https://docs.flashbots.net/flashbots-auction/overview). Điều này cho phép họ sắp xếp các giao dịch trong các khối sắp tới để có lợi nhuận tối đa ([MEV](/developers/docs/mev/#mev-extraction)). +4. Một trong các nút xác thực trên mạng là nút đề xuất khối cho slot hiện tại, trước đó đã được chọn ngẫu nhiên bằng RANDAO. Nút này chịu trách nhiệm xây dựng và phát khối tiếp theo sẽ được thêm vào chuỗi khối Ethereum và cập nhật trạng thái toàn cầu. Nút này bao gồm ba phần: ứng dụng thực thi, ứng dụng đồng thuận và ứng dụng xác thực. Ứng dụng thực thi sẽ đóng gói các giao dịch từ khu vực chờ cục bộ thành "tải trọng thực thi" và thực thi chúng cục bộ để tạo ra thay đổi trạng thái. Thông tin này được chuyển đến ứng dụng đồng thuận, tại đó tải trọng thực thi được gói lại thành một phần của "khối đèn hiệu" cũng chứa thông tin về phần thưởng, hình phạt, lệnh cắt, chứng thực, v.v. cho phép mạng đồng ý về trình tự các khối ở đầu chuỗi. Giao tiếp giữa máy khách thực thi và máy khách đồng thuận được mô tả chi tiết hơn trong [Kết nối Máy khách Đồng thuận và Máy khách Thực thi](/developers/docs/networking-layer/#connecting-clients). +5. Các nút khác nhận được khối beacon mới trên mạng gossip lớp đồng thuận. Chúng chuyển nó đến ứng dụng thực hiện, tại đó các giao dịch được thực hiện lại cục bộ để đảm bảo thay đổi trạng thái được đề xuất là hợp lệ. Máy khách trình xác thực sau đó chứng thực rằng khối đó hợp lệ và là khối hợp lý tiếp theo trong khung nhìn của họ về chuỗi (nghĩa là nó được xây dựng trên chuỗi có trọng số chứng thực lớn nhất như được định nghĩa trong [quy tắc lựa chọn phân nhánh](/developers/docs/consensus-mechanisms/pos/#fork-choice)). Khối được thêm vào cơ sở dữ liệu cục bộ tại mỗi nút chứng thực khối đó. +6. Giao dịch có thể được coi là "hoàn tất" nếu nó trở thành một phần của chuỗi có "liên kết siêu đa số" giữa hai điểm kiểm tra. Các điểm kiểm tra xuất hiện vào đầu mỗi tham số epoch và chúng tồn tại để tính đến thực tế là chỉ có một tập hợp con người xác thực đang hoạt động chứng thực trong mỗi slot, nhưng tất cả người xác thực đang hoạt động đều chứng thực trong mỗi tham số epoch. Do đó, chỉ giữa tham số epoch thì mới có thể chứng minh được 'liên kết siêu đa số' (đây là trường hợp 66% tổng số ETH được đặt cọc trên mạng đồng ý về hai điểm kiểm tra). + +Bạn có thể tìm thấy thông tin chi tiết hơn về tính kết luận cuối cùng bên dưới. + +## Tính kết luận cuối cùng {#finality} + +Một giao dịch có tính "cuối cùng" trong các mạng phân tán khi nó là một phần của khối không thể thay đổi nếu không có một lượng lớn ETH bị đốt cháy. Trên Ethereum bằng chứng cổ phần (Proof-of-Stake), việc này được quản lý bằng cách sử dụng các khối "checkpoint". Khối đầu tiên trong mỗi kỷ nguyên (epoch) là một checkpoint. Người xác thực bỏ phiếu cho các cặp checkpoint mà nó cho là hợp lệ. Nếu một cặp checkpoint thu hút được số phiếu đại diện cho ít nhất 2/3 tổng số ETH đã được stake thì checkpoint sẽ được nâng cấp. Khi cả hai (target) trở thành "được chứng minh là đúng" (justified) càng gần với hiện tại. Thì cả hai cái trước đó "được chứng minh là đúng" (justified) càng sớm bởi vì nó là "mục tiêu" (target) của kỷ nguyên (epoch) trước. Giờ nó được nâng cấp lên thành "hoàn thiện" (finalized). Quá trình nâng cấp các điểm kiểm tra này được xử lý bởi **[Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437)**. Casper-FFG là một công cụ xác định tính cuối cùng của khối cho sự đồng thuận. Một khi một khối được hoàn tất, nó không thể bị hoàn lại hoặc thay đổi nếu không có sự cắt giảm đa số người đặt cược, khiến nó không khả thi về mặt kinh tế. + +Để hoàn tác một khối đã hoàn tất, kẻ tấn công sẽ phải mất ít nhất một phần ba tổng nguồn cung ETH đã đặt cọc. Lý do chính xác cho điều này được giải thích trong [bài đăng trên blog của Ethereum Foundation](https://blog.ethereum.org/2016/05/09/on-settlement-finality/). Vì tính kết luận cuối cùng đòi hỏi phải có đa số hai phần ba, nên kẻ tấn công có thể ngăn chặn mạng đạt được tính kết luận cuối cùng bằng cách bỏ phiếu bằng một phần ba tổng số đặt cọt. Có một cơ chế để chống lại điều này: [rò rỉ do không hoạt động](https://eth2book.info/bellatrix/part2/incentives/inactivity). Tính năng này được kích hoạt bất cứ khi nào chuỗi không hoàn tất trong hơn bốn tham số epoch. Rò rỉ không hoạt động sẽ làm mất đi số ETH đã đặt cọc từ những người xác thực bỏ phiếu chống lại đa số, cho phép đa số giành lại được hai phần ba và hoàn thiện chuỗi. + +## Bảo mật kinh tế tiền mã hóa {#crypto-economic-security} + +Vận hành trình xác thực là một cam kết. Người xác thực được kỳ vọng sẽ duy trì đủ phần cứng và kết nối để tham gia xác thực khối và đề xuất. Đổi lại, người xác thực được trả bằng ETH (số dư đặt cọc của họ tăng lên). Mặt khác, việc tham gia với tư cách là người xác thực cũng mở ra những con đường mới cho người dùng tấn công mạng để trục lợi cá nhân hoặc phá hoại. Để ngăn chặn điều này, người xác thực sẽ mất phần thưởng ETH nếu họ không tham gia khi được yêu cầu và đặt cọc hiện tại của họ có thể bị hủy nếu họ hành xử không trung thực. Hai hành vi chính có thể bị coi là không trung thực: đề xuất nhiều khối trong một slot duy nhất (lập lờ) và gửi các chứng thực mâu thuẫn. + +Số lượng ETH bị cắt giảm phụ thuộc vào số lượng người xác thực cũng bị cắt giảm tại cùng thời điểm. Điều này được gọi là [\"hình phạt tương quan\"](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty), và nó có thể là nhỏ (~1% cổ phần cho một trình xác thực bị cắt giảm một mình) hoặc có thể dẫn đến việc 100% cổ phần của trình xác thực bị phá hủy (sự kiện cắt giảm hàng loạt). Nó được áp dụng vào giữa giai đoạn thoát bắt buộc bắt đầu bằng hình phạt ngay lập tức (tối đa 1 ETH) vào Ngày 1, hình phạt tương quan vào Ngày 18 và cuối cùng là bị loại khỏi mạng vào Ngày 36. Họ nhận được những hình phạt chứng thực nhỏ mỗi ngày vì họ có mặt trên mạng nhưng không gửi phiếu bầu. Tất cả điều này có nghĩa là một cuộc tấn công phối hợp sẽ rất tốn kém cho kẻ tấn công. + +## Lựa chọn phân nhánh {#fork-choice} + +Khi mạng hoạt động tối ưu và trung thực, sẽ chỉ có một khối mới ở đầu chuỗi và tất cả người xác thực đều chứng thực điều đó. Tuy nhiên, người xác thực có thể có quan điểm khác nhau về người đứng đầu chuỗi do độ trễ của mạng hoặc do người đề xuất khối đã không rõ ràng. Do đó, ứng dụng đồng thuận cần có một thuật toán để quyết định nên ưu tiên cái nào. Thuật toán được sử dụng trong bằng chứng cổ phần của Ethereum được gọi là [LMD-GHOST](https://arxiv.org/pdf/2003.03052.pdf), và nó hoạt động bằng cách xác định phân nhánh có trọng số chứng thực lớn nhất trong lịch sử của nó. + +## Bằng chứng cổ phần và bảo mật {#pos-and-security} + +Mối đe dọa về một [cuộc tấn công 51%](https://www.investopedia.com/terms/1/51-attack.asp) vẫn tồn tại trên bằng chứng cổ phần cũng như trên bằng chứng công việc, nhưng nó thậm chí còn rủi ro hơn cho những kẻ tấn công. Kẻ tấn công sẽ cần 51% số ETH đã đặt cọc. Sau đó, họ có thể sử dụng chứng thực riêng để đảm bảo rằng nĩa họ ưa thích là nĩa có nhiều chứng thực tích lũy nhất. 'Trọng số' của các chứng thực tích lũy là những gì ứng dụng đồng thuận sử dụng để xác định chuỗi chính xác, do đó kẻ tấn công này sẽ có thể biến nĩa của họ thành nĩa chuẩn. Tuy nhiên, điểm mạnh của bằng chứng cổ phần so với bằng chứng công việc là cộng đồng linh hoạt trong phản công. Ví dụ, những người xác thực trung thực có thể quyết định tiếp tục xây dựng trên chuỗi thiểu số và bỏ qua nĩa của kẻ tấn công trong khi khuyến khích các ứng dụng, sàn giao dịch và nhóm làm như vậy. Họ cũng có thể quyết định buộc kẻ tấn công phải rời khỏi mạng và phá hủy số ETH đã đặt cọc của họ. Đây là biện pháp phòng thủ kinh tế mạnh mẽ chống lại cuộc tấn công 51%. + +Ngoài các cuộc tấn công 51%, kẻ xấu cũng có thể thực hiện các hoạt động độc hại khác, chẳng hạn như: + +- các cuộc tấn công tầm xa (mặc dù tính kết luận cuối cùng vô hiệu hóa hướng tấn công này) +- 'tổ chức lại' tầm ngắn (mặc dù việc đề xuất ưu tiên và thời hạn chứng thực làm giảm bớt điều này) +- các cuộc tấn công bật nảy và cân bằng (cũng được giảm nhẹ bằng đề xuất ưu tiên và các cuộc tấn công này dù sao cũng chỉ được chứng minh trong điều kiện mạng lý tưởng) +- tấn công tuyết lở (bị vô hiệu hóa bởi quy tắc thuật toán lựa chọn nĩa chỉ xem xét thông điệp mới nhất) + +Nhìn chung, bằng chứng cổ phần được triển khai trên Ethereum đã được chứng minh là bảo mật hơn về mặt kinh tế so với bằng chứng công việc. + +## Ưu và nhược điểm {#pros-and-cons} + +| Ưu điểm | Nhược điểm | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | +| Đặt cọc giúp cá nhân dễ dàng tham gia vào bảo mật mạng, thúc đẩy tính phi tập trung. nút người xác thực có thể chạy trên máy tính xách tay thông thường. Nhóm đặt cọc cho phép người dùng đặt cọc mà không cần có 32 ETH. | Bằng chứng cổ phần còn mới và ít được thử nghiệm thực tế hơn so với bằng chứng công việc | +| Đặt cược có tính phi tập trung cao hơn. Các hiệu quả kinh tế theo quy mô không áp dụng theo cách giống như đối với khai thác PoW. | Bằng chứng cổ phần phức tạp hơn khi triển khai so với bằng chứng công việc | +| Bằng chứng cổ phần cung cấp tính bảo mật kinh tế tiền điện tử cao hơn bằng chứng công việc | Người dùng cần chạy ba phần mềm để tham gia vào cơ chế bằng chứng cổ phần của Ethereum. | +| Cần phải phát hành ít ETH mới hơn để khuyến khích những người tham gia mạng | | + +### So sánh với bằng chứng công việc {#comparison-to-proof-of-work} + +Ethereum ban đầu sử dụng bằng chứng công việc nhưng đã chuyển sang bằng chứng cổ phần vào tháng 9 năm 2022. PoS có một số ưu điểm so với PoW, chẳng hạn như: + +- hiệu quả năng lượng tốt hơn – không cần sử dụng nhiều năng lượng cho các tính toán bằng chứng công việc +- rào cản gia nhập thấp hơn, yêu cầu phần cứng giảm – không cần phần cứng tinh nhuệ để có cơ hội tạo ra các khối mới +- giảm rủi ro tập trung hóa – bằng chứng cổ phần sẽ dẫn đến nhiều nút bảo mật mạng hơn +- vì nhu cầu năng lượng thấp nên cần ít phát hành ETH hơn để khuyến khích tham gia +- hình phạt kinh tế cho hành vi sai trái làm cho cuộc tấn công kiểu 51% tốn kém hơn cho kẻ tấn công so với bằng chứng công việc +- cộng đồng có thể dùng đến biện pháp phục hồi xã hội của một chuỗi trung thực nếu một cuộc tấn công 51% vượt qua được các biện pháp phòng thủ kinh tế tiền điện tử. + +## Đọc thêm {#further-reading} + +- [Câu hỏi thường gặp về Bằng chứng Cổ phần](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html) _Vitalik Buterin_ +- [Bằng chứng Cổ phần là gì](https://consensys.net/blog/blockchain-explained/what-is-proof-of-stake/) _ConsenSys_ +- [Bằng chứng Cổ phần là gì và Tại sao nó lại quan trọng](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463) _Vitalik Buterin_ +- [Tại sao nên dùng Bằng chứng Cổ phần (Tháng 11 năm 2020)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) _Vitalik Buterin_ +- [Bằng chứng Cổ phần: Làm thế nào tôi học được cách yêu tính chủ quan yếu](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) _Vitalik Buterin_ +- [Tấn công và phòng thủ trên Ethereum bằng chứng cổ phần](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) +- [Triết lý Thiết kế Bằng chứng Cổ phần](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) _Vitalik Buterin_ +- [Video: Vitalik Buterin giải thích về bằng chứng cổ phần cho Lex Fridman](https://www.youtube.com/watch?v=3yrqBG-7EVE) + +## Các chủ đề liên quan {#related-topics} + +- [Bằng chứng công việc](/developers/docs/consensus-mechanisms/pow/) +- [Bằng chứng ủy quyền](/developers/docs/consensus-mechanisms/poa/) diff --git a/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/keys/index.md b/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/keys/index.md new file mode 100644 index 00000000000..a0197ad5e8b --- /dev/null +++ b/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/keys/index.md @@ -0,0 +1,102 @@ +--- +title: "Các khóa trong Ethereum bằng chứng cổ phần" +description: "Giải thích về các khóa được sử dụng trong cơ chế đồng thuận bằng chứng cổ phần của Ethereum" +lang: vi +--- + +Ethereum bảo mật tài sản của người dùng bằng cách sử dụng mật mã hóa khóa công khai-riêng tư. Khóa công khai được sử dụng làm cơ sở cho một địa chỉ Ethereum—tức là nó hiển thị công khai và được sử dụng như một mã định danh duy nhất. Khóa riêng tư (hay khóa 'bí mật') chỉ nên được chủ tài khoản truy cập. Khóa riêng tư được sử dụng để 'ký' các giao dịch và dữ liệu để mật mã học có thể chứng minh rằng chủ sở hữu chấp thuận một hành động nào đó của một khóa riêng tư cụ thể. + +Các khóa của Ethereum được tạo bằng [mật mã hóa đường cong elip](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography). + +Tuy nhiên, khi Ethereum chuyển từ [bằng chứng công việc](/developers/docs/consensus-mechanisms/pow) sang [bằng chứng cổ phần](/developers/docs/consensus-mechanisms/pos), một loại khóa mới đã được thêm vào Ethereum. Các khóa ban đầu vẫn hoạt động chính xác như trước—không có thay đổi nào đối với các khóa dựa trên đường cong elip bảo mật tài khoản. Tuy nhiên, người dùng cần một loại khóa mới để tham gia vào bằng chứng cổ phần bằng cách đặt cọc ETH và chạy trình xác thực. Nhu cầu này phát sinh từ những thách thức về khả năng mở rộng liên quan đến nhiều thông báo được truyền giữa một số lượng lớn trình xác thực, đòi hỏi một phương pháp mã hóa có thể dễ dàng tổng hợp để giảm lượng giao tiếp cần thiết cho mạng lưới đi đến đồng thuận. + +Loại khóa mới này sử dụng lược đồ chữ ký [**Boneh-Lynn-Shacham (BLS)**](https://wikipedia.org/wiki/BLS_digital_signature). BLS cho phép tổng hợp chữ ký rất hiệu quả nhưng cũng cho phép thiết kế ngược các khóa trình xác thực riêng lẻ được tổng hợp và lý tưởng cho việc quản lý các hành động giữa các trình xác thực. + +## Hai loại khóa của trình xác thực {#two-types-of-keys} + +Trước khi chuyển sang bằng chứng cổ phần, người dùng Ethereum chỉ có một khóa riêng tư dựa trên đường cong elip duy nhất để truy cập vào tiền của họ. Với sự ra đời của bằng chứng cổ phần, những người dùng muốn trở thành người đặt cọc đơn lẻ cũng cần có một **khóa trình xác thực** và một **khóa rút tiền**. + +### Khóa trình xác thực {#validator-key} + +Khóa ký của trình xác thực bao gồm hai yếu tố: + +- Khóa **riêng tư** của trình xác thực +- Khóa **công khai** của trình xác thực + +Mục đích của khóa riêng tư của trình xác thực là ký các hoạt động trên chuỗi như đề xuất khối và chứng thực. Vì vậy, các khóa này phải được giữ trong ví nóng. + +Sự linh hoạt này có ưu điểm là di chuyển các khóa ký của trình xác thực rất nhanh từ thiết bị này sang thiết bị khác, tuy nhiên, nếu chúng bị mất hoặc bị đánh cắp, kẻ trộm có thể **hành động độc hại** theo một số cách: + +- Khiến trình xác thực bị phạt cắt giảm bằng cách: + - Trở thành người đề xuất và ký hai khối beacon khác nhau cho cùng một vị trí + - Trở thành người chứng thực và ký một chứng thực "bao quanh" một chứng thực khác + - Trở thành người chứng thực và ký hai chứng thực khác nhau có cùng mục tiêu +- Buộc thoát tự nguyện, điều này ngăn trình xác thực tham gia đặt cọc và cấp quyền truy cập vào số dư ETH của nó cho chủ sở hữu khóa rút tiền + +**Khóa công khai của trình xác thực** được bao gồm trong dữ liệu giao dịch khi người dùng gửi ETH vào hợp đồng gửi tiền đặt cọc. Điều này được gọi là _dữ liệu gửi tiền_ và nó cho phép Ethereum xác định trình xác thực. + +### Thông tin xác thực rút tiền {#withdrawal-credentials} + +Mỗi trình xác thực có một thuộc tính được gọi là _thông tin xác thực rút tiền_. Byte đầu tiên của trường 32 byte này xác định loại tài khoản: `0x00` đại diện cho thông tin xác thực BLS ban đầu (trước Shapella, không thể rút), `0x01` đại diện cho thông tin xác thực cũ trỏ đến một địa chỉ thực thi và `0x02` đại diện cho loại thông tin xác thực gộp hiện đại. + +Các trình xác thực có khóa BLS `0x00` phải cập nhật các thông tin xác thực này để trỏ đến một địa chỉ thực thi nhằm kích hoạt các khoản thanh toán số dư vượt mức hoặc rút toàn bộ tiền khỏi việc đặt cọc. Điều này có thể được thực hiện bằng cách cung cấp một địa chỉ thực thi trong dữ liệu gửi tiền trong quá trình tạo khóa ban đầu, _HOẶC_ bằng cách sử dụng khóa rút tiền sau đó để ký và phát một thông báo `BLSToExecutionChange`. + +[Thông tin thêm về thông tin xác thực rút tiền của trình xác thực](/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/) + +### Khóa rút tiền {#withdrawal-key} + +Khóa rút tiền sẽ được yêu cầu để cập nhật thông tin xác thực rút tiền nhằm trỏ đến một địa chỉ thực thi, nếu không được đặt trong lần gửi tiền ban đầu. Điều này sẽ cho phép các khoản thanh toán số dư vượt mức bắt đầu được xử lý và cũng sẽ cho phép người dùng rút toàn bộ ETH đã đặt cọc của họ. + +Cũng giống như các khóa của trình xác thực, các khóa rút tiền cũng bao gồm hai thành phần: + +- Khóa **riêng tư** rút tiền +- Khóa **công khai** rút tiền + +Mất khóa này trước khi cập nhật thông tin xác thực rút tiền thành loại `0x01` đồng nghĩa với việc mất quyền truy cập vào số dư của trình xác thực. Trình xác thực vẫn có thể ký các chứng thực và các khối vì các hành động này yêu cầu khóa riêng tư của trình xác thực, tuy nhiên có rất ít hoặc không có động lực nếu khóa rút tiền bị mất. + +Việc tách các khóa của trình xác thực khỏi các khóa tài khoản Ethereum cho phép một người dùng duy nhất chạy nhiều trình xác thực. + +![sơ đồ khóa của trình xác thực](validator-key-schematic.png) + +**Lưu ý**: Việc thoát khỏi nhiệm vụ đặt cọc và rút số dư của trình xác thực hiện tại yêu cầu ký một [thông báo thoát tự nguyện (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) bằng khóa của trình xác thực. Tuy nhiên, [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) là một đề xuất sẽ cho phép người dùng kích hoạt việc thoát của trình xác thực và rút số dư của nó bằng cách ký các thông báo thoát bằng khóa rút tiền trong tương lai. Điều này sẽ giảm các giả định về sự tin cậy bằng cách cho phép những người đặt cọc ủy quyền ETH cho [các nhà cung cấp dịch vụ đặt cọc](/staking/saas/#what-is-staking-as-a-service) vẫn giữ quyền kiểm soát tiền của họ. + +## Tạo khóa từ một cụm từ khởi tạo {#deriving-keys-from-seed} + +Nếu cứ 32 ETH được đặt cọc lại yêu cầu một bộ 2 khóa hoàn toàn độc lập mới, việc quản lý khóa sẽ nhanh chóng trở nên khó khăn, đặc biệt là đối với những người dùng chạy nhiều trình xác thực. Thay vào đó, nhiều khóa trình xác thực có thể được tạo ra từ một bí mật chung duy nhất và việc lưu trữ bí mật duy nhất đó cho phép truy cập vào nhiều khóa trình xác thực. + +[Các từ gợi nhớ](https://en.bitcoinwiki.org/wiki/Mnemonic_phrase) và các đường dẫn là những tính năng nổi bật mà người dùng thường gặp khi [họ truy cập](https://ethereum.stackexchange.com/questions/19055/what-is-the-difference-between-m-44-60-0-0-and-m-44-60-0) ví của họ. Từ gợi nhớ là một chuỗi các từ hoạt động như một hạt giống ban đầu cho một khóa riêng tư. Khi được kết hợp với dữ liệu bổ sung, từ gợi nhớ sẽ tạo ra một hàm băm được gọi là 'khóa chính'. Điều này có thể được coi là gốc của một cây. Các nhánh từ gốc này sau đó có thể được tạo ra bằng cách sử dụng một đường dẫn phân cấp để các nút con có thể tồn tại dưới dạng sự kết hợp của hàm băm của nút cha và chỉ mục của chúng trong cây. Đọc về các tiêu chuẩn [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) và [BIP-19](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) để tạo khóa dựa trên từ gợi nhớ. + +Các đường dẫn này có cấu trúc sau, sẽ quen thuộc với những người dùng đã tương tác với ví phần cứng: + +``` +m/44'/60'/0'/0` +``` + +Các dấu gạch chéo trong đường dẫn này phân tách các thành phần của khóa riêng tư như sau: + +``` +master_key / purpose / coin_type / account / change / address_index +``` + +Logic này cho phép người dùng đính kèm càng nhiều trình xác thực càng tốt vào một **cụm từ gợi nhớ** duy nhất vì gốc cây có thể là chung và sự khác biệt có thể xảy ra ở các nhánh. Người dùng có thể **tạo ra bất kỳ số lượng khóa nào** từ cụm từ gợi nhớ. + +``` + [m / 0] + / + / +[m] - [m / 1] + \ + \ + [m / 2] +``` + +Mỗi nhánh được phân tách bằng dấu `/` vì vậy `m/2` có nghĩa là bắt đầu với khóa chính và đi theo nhánh 2. Trong sơ đồ bên dưới, một cụm từ gợi nhớ duy nhất được sử dụng để lưu trữ ba khóa rút tiền, mỗi khóa có hai trình xác thực được liên kết. + +![logic khóa trình xác thực](multiple-keys.png) + +## Đọc thêm {#further-reading} + +- [Bài đăng trên blog của Ethereum Foundation bởi Carl Beekhuizen](https://blog.ethereum.org/2020/05/21/keys/) +- [Tạo khóa EIP-2333 BLS12-381](https://eips.ethereum.org/EIPS/eip-2333) +- [EIP-7002: Lối thoát được kích hoạt bởi Lớp Thực thi](https://web.archive.org/web/20250125035123/https://research.2077.xyz/eip-7002-unpacking-improvements-to-staking-ux-post-merge) +- [Quản lý khóa ở quy mô lớn](https://docs.ethstaker.cc/ethstaker-knowledge-base/scaled-node-operators/key-management-at-scale) diff --git a/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md b/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md new file mode 100644 index 00000000000..58b63339ec5 --- /dev/null +++ b/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md @@ -0,0 +1,69 @@ +--- +title: "Minh chứng theo cổ phần và minh chứng theo lao động" +description: "Một sự so sánh giữa minh chứng theo cổ phần và minh chứng theo lao động của Ethereum nằm ở cơ chế đồng thuận" +lang: vi +--- + +Tại thời điếm sơ khai của Ethereum, minh chứng theo cổ phần khi ấy cẫn cần rất nhiều nghiên cứu và phát triển trước khi có thể đủ độ tin cậy bảo mật cho Ethereum. Minh chứng theo lao động lại là một phương thức đơn giản hơn hẳn đã được chứng minh bởi Bitcoin, có nghĩa là các nhà phát triển có thể triển khai cơ chế đó ngay khi khởi tạo Ethereum. Để minh chứng theo cổ phần có thể được sử dụng họ cần hoàn thiện nó trong vòng 8 năm sau đó. + +Bài viết này sẽ giải thích lý do đằng sau việc Ethereum chuyển đổi từ cơ chế minh chứng theo lao động sang minh chứng theo cổ phần và những hệ quả mang lại. + +## Bảo mật {#security} + +Các nhà nghiên cứu có căn cứ để cho rằng minh chứng theo cổ phần sẽ an toàn hơn minh chứng theo lao động. Tuy nhiên, nó chỉ mới được triển khai gần đây trên mạng chính thức của Ethereum nên sẽ có ít độ tin cậy qua thời gian hơn minh chứng theo lao động. Mục tiếp theo sẽ so sánh lợi và hại giữa mô hình bảo mật của minh chứng theo cổ phần và minh chứng theo lao động. + +### Chi phí để tấn công {#cost-to-attack} + +Trong cơ chế minh chứng theo cổ phần, người chứng minh cần yêu cầu tích trữ ("ký gửi") ít nhất 32 ETH cho một hợp đồng thông minh. Người minh chứng nếu vi phạm sẽ bị huỷ số ether đã gửi để trừng phạt. Để mạng lưới thống nhất, ít nhất 66% số người minh chứng cần bỏ phiếu với cùng một nhóm khối. Các khối được bỏ phiếu bởi >=66% số cổ phần sẽ trở nên "hoàn thiện", nghĩa là chúng không thể bị xóa hoặc sắp xếp lại. + +Tấn công mạng có nghĩa là ngăn việc chuỗi xác nhận hay đảm bảo một tập hợp cụ thể các khối mà bằng cách nào đó có lợi cho những kẻ tấn công. Điều này buộc kẻ tấn công phải bẻ hướng sự đồng thuận trung thực, hoặc bằng cách gom một lượng lớn ETH để tự mình bỏ phiếu, hoặc bằng cách lừa các validator trung thực bỏ phiếu theo ý hắn. Ngoại trừ những kiểu tấn công phức tạp và hiếm khi xảy ra nhằm đánh lừa validator trung thực, chi phí để tấn công Ethereum chính là lượng ETH mà kẻ tấn công phải stake đủ lớn để xoay chuyển sự đồng thuận theo ý mình. + +Chi phí tấn công thấp nhất là >33% tổng số cổ phần. Kẻ tấn công nắm giữ >33% tổng số cổ phần có thể gây ra sự chậm trễ trong việc hoàn thiện chỉ bằng cách ngoại tuyến. Đây là một vấn đề tương đối nhỏ đối với mạng vì có một cơ chế được gọi là "rò rỉ do không hoạt động" giúp rò rỉ cổ phần từ các trình xác thực ngoại tuyến cho đến khi phần lớn trực tuyến chiếm 66% cổ phần và có thể hoàn thiện chuỗi một lần nữa. Về mặt lý thuyết, kẻ tấn công cũng có thể gây ra việc hoàn thiện kép với hơn 33% tổng số cổ phần bằng cách tạo ra hai khối thay vì một khi họ được yêu cầu làm nhà sản xuất khối và sau đó bỏ phiếu kép với tất cả các trình xác thực của họ. Mỗi phân nhánh chỉ yêu cầu 50% các trình xác thực trung thực còn lại nhìn thấy mỗi khối trước, vì vậy nếu họ quản lý để định giờ thông điệp của mình một cách chính xác, họ có thể hoàn thiện cả hai phân nhánh. Khả năng thành công của việc này thấp, nhưng nếu kẻ tấn công có thể gây ra hoàn thiện kép, cộng đồng Ethereum sẽ phải quyết định đi theo một phân nhánh, trong trường hợp đó các trình xác thực của kẻ tấn công chắc chắn sẽ bị chém phạt ở phân nhánh còn lại. + +Với >33% tổng số cổ phần, kẻ tấn công có cơ hội gây ảnh hưởng nhỏ (trì hoãn hoàn thiện) hoặc nghiêm trọng hơn (hoàn thiện kép) lên mạng Ethereum. Với hơn 14.000.000 ETH được đặt cược trên mạng và mức giá đại diện là 1000 USD/ETH, chi phí tối thiểu để thực hiện các cuộc tấn công này là `1000 x 14.000.000 x 0.33 = 4.620.000.000 USD`. Kẻ tấn công sẽ mất số tiền này thông qua việc bị chém phạt và bị loại khỏi mạng. Để tấn công lần nữa, họ sẽ phải tích lũy >33% cổ phần (một lần nữa) và bị mất nó (một lần nữa). Mỗi nỗ lực tấn công mạng sẽ tốn >4,6 tỷ USD (với giá 1000 USD/ETH và 14 triệu ETH được đặt cược). Kẻ tấn công cũng bị loại khỏi mạng khi bị chém phạt, và họ phải tham gia một hàng đợi kích hoạt để tham gia lại. Điều này có nghĩa là tốc độ của một cuộc tấn công lặp lại không chỉ bị giới hạn bởi tốc độ mà kẻ tấn công có thể tích lũy >33% tổng số cổ phần mà còn bởi thời gian cần thiết để đưa tất cả các trình xác thực của họ lên mạng. Mỗi lần kẻ tấn công tấn công, họ sẽ nghèo đi nhiều, và phần còn lại của cộng đồng sẽ giàu lên, nhờ vào cú sốc nguồn cung kết quả. + +Các cuộc tấn công khác, chẳng hạn như tấn công 51% hoặc đảo ngược hoàn thiện với 66% tổng số cổ phần, đòi hỏi nhiều ETH hơn đáng kể và tốn kém hơn nhiều đối với kẻ tấn công. + +So sánh điều này với bằng chứng công việc. Chi phí để phát động một cuộc tấn công vào Ethereum bằng chứng công việc là chi phí để sở hữu ổn định >50% tổng tốc độ băm của mạng. Điều này tương đương với chi phí phần cứng và vận hành của đủ sức mạnh tính toán để cạnh tranh với các thợ đào khác nhằm tính toán các giải pháp bằng chứng công việc một cách nhất quán. Ethereum chủ yếu được đào bằng GPU thay vì ASIC, điều này giúp giữ chi phí thấp (mặc dù nếu Ethereum vẫn ở lại trên bằng chứng công việc, việc đào bằng ASIC có thể đã trở nên phổ biến hơn). Một đối thủ sẽ phải mua rất nhiều phần cứng và trả tiền điện để chạy nó nhằm tấn công mạng Ethereum bằng chứng công việc, nhưng tổng chi phí sẽ ít hơn chi phí cần thiết để tích lũy đủ ETH để phát động một cuộc tấn công. Một cuộc tấn công 51% trên bằng chứng công việc rẻ hơn ~[20 lần](https://youtu.be/1m12zgJ42dI?t=1562) so với bằng chứng cổ phần. Nếu cuộc tấn công bị phát hiện và chuỗi được phân nhánh cứng để loại bỏ các thay đổi của họ, kẻ tấn công có thể liên tục sử dụng cùng một phần cứng để tấn công phân nhánh mới. + +### Độ phức tạp {#complexity} + +Bằng chứng cổ phần phức tạp hơn nhiều so với bằng chứng công việc. Đây có thể là một điểm có lợi cho bằng chứng công việc vì khó có thể vô tình đưa các lỗi hoặc hiệu ứng không mong muốn vào các giao thức đơn giản hơn. Tuy nhiên, sự phức tạp đã được chế ngự bởi nhiều năm nghiên cứu và phát triển, mô phỏng và triển khai mạng thử nghiệm. Giao thức bằng chứng cổ phần đã được năm nhóm riêng biệt triển khai độc lập (trên mỗi lớp thực thi và lớp đồng thuận) bằng năm ngôn ngữ lập trình, mang lại khả năng phục hồi chống lại các lỗi của máy khách. + +Để phát triển và kiểm tra logic đồng thuận bằng chứng cổ phần một cách an toàn, Chuỗi Beacon đã được ra mắt hai năm trước khi bằng chứng cổ phần được triển khai trên Mạng chính Ethereum. Chuỗi Beacon hoạt động như một môi trường thử nghiệm để kiểm tra bằng chứng cổ phần, vì nó là một chuỗi khối trực tiếp triển khai logic đồng thuận bằng chứng cổ phần nhưng không động đến các giao dịch Ethereum thực — thực chất chỉ là đi đến sự đồng thuận trên chính nó. Sau khi nó đã ổn định và không có lỗi trong một thời gian đủ dài, Chuỗi Beacon đã được "hợp nhất" với Mạng chính Ethereum. Tất cả những điều này đã góp phần chế ngự sự phức tạp của bằng chứng cổ phần đến mức nguy cơ về các hậu quả không mong muốn hoặc lỗi máy khách là rất thấp. + +### Bề mặt tấn công {#attack-surface} + +Bằng chứng cổ phần phức tạp hơn bằng chứng công việc, điều đó có nghĩa là có nhiều vectơ tấn công tiềm năng hơn cần xử lý. Thay vì một mạng ngang hàng kết nối các máy khách, có hai mạng, mỗi mạng triển khai một giao thức riêng biệt. Việc có một trình xác thực cụ thể được chọn trước để đề xuất một khối trong mỗi slot tạo ra tiềm năng cho các cuộc tấn công từ chối dịch vụ, trong đó lượng lớn lưu lượng mạng làm cho trình xác thực cụ thể đó ngoại tuyến. + +Cũng có những cách mà kẻ tấn công có thể cẩn thận định thời gian phát hành các khối hoặc các chứng thực của họ để chúng được nhận bởi một tỷ lệ nhất định của mạng lưới trung thực, ảnh hưởng đến họ để bỏ phiếu theo những cách nhất định. Cuối cùng, một kẻ tấn công có thể chỉ cần tích lũy đủ ETH để đặt cược và thống trị cơ chế đồng thuận. Mỗi [vectơ tấn công này đều có các biện pháp phòng thủ liên quan](/developers/docs/consensus-mechanisms/pos/attack-and-defense), nhưng chúng không tồn tại để được phòng thủ dưới bằng chứng công việc. + +## Tính phi tập trung {#decentralization} + +Bằng chứng cổ phần phi tập trung hơn bằng chứng công việc vì các cuộc chạy đua vũ trang phần cứng khai thác có xu hướng loại bỏ các cá nhân và tổ chức nhỏ do giá cả. Mặc dù về mặt kỹ thuật, bất kỳ ai cũng có thể bắt đầu khai thác với phần cứng khiêm tốn, nhưng khả năng nhận được bất kỳ phần thưởng nào của họ là cực kỳ nhỏ so với các hoạt động khai thác của tổ chức. Với bằng chứng cổ phần, chi phí đặt cược và tỷ lệ lợi nhuận trên số cổ phần đó là như nhau đối với mọi người. Hiện tại, cần 32 ETH để chạy một trình xác thực. + +Mặt khác, sự ra đời của các công cụ phái sinh đặt cược thanh khoản đã dẫn đến những lo ngại về tập trung hóa vì một vài nhà cung cấp lớn quản lý lượng lớn ETH đã đặt cược. Điều này có vấn đề và cần được khắc phục càng sớm càng tốt, nhưng nó cũng phức tạp hơn vẻ bề ngoài. Các nhà cung cấp dịch vụ đặt cược tập trung không nhất thiết phải có quyền kiểm soát tập trung đối với các trình xác thực - thường đó chỉ là một cách để tạo ra một bể ETH trung tâm mà nhiều nhà điều hành nút độc lập có thể đặt cược mà không cần mỗi người tham gia phải có 32 ETH của riêng mình. + +Lựa chọn tốt nhất cho Ethereum là các trình xác thực được chạy cục bộ trên máy tính tại nhà, nhằm tối đa hóa tính phi tập trung. Đây là lý do tại sao Ethereum chống lại những thay đổi làm tăng yêu cầu phần cứng để chạy một nút/trình xác thực. + +## Tính bền vững {#sustainability} + +Bằng chứng cổ phần là một cách bảo mật chuỗi khối với chi phí carbon thấp. Theo bằng chứng công việc, các thợ đào cạnh tranh để giành quyền khai thác một khối. Các thợ đào thành công hơn khi họ có thể thực hiện các phép tính nhanh hơn, điều này khuyến khích đầu tư vào phần cứng và tiêu thụ năng lượng. Điều này đã được quan sát thấy đối với Ethereum trước khi nó chuyển sang bằng chứng cổ phần. Ngay trước khi chuyển đổi sang bằng chứng cổ phần, Ethereum đã tiêu thụ khoảng 78 TWh/năm - tương đương với một quốc gia nhỏ. Tuy nhiên, việc chuyển sang bằng chứng cổ phần đã giảm chi tiêu năng lượng này khoảng ~99,98%. Bằng chứng cổ phần đã biến Ethereum thành một nền tảng tiết kiệm năng lượng, ít carbon. + +[Tìm hiểu thêm về mức tiêu thụ năng lượng của Ethereum](/energy-consumption) + +## Phát hành {#issuance} + +Ethereum bằng chứng cổ phần có thể trả cho bảo mật của mình bằng cách phát hành ít coin hơn nhiều so với Ethereum bằng chứng công việc vì các trình xác thực không phải trả chi phí điện cao. Kết quả là, ETH có thể giảm lạm phát hoặc thậm chí trở nên giảm phát khi một lượng lớn ETH bị đốt cháy. Mức lạm phát thấp hơn có nghĩa là bảo mật của Ethereum rẻ hơn so với khi sử dụng bằng chứng công việc. + +## Tìm hiểu thêm từ video trực quan? Người học qua hình ảnh {#visual-learner} + +Xem Justin Drake giải thích những lợi ích của bằng chứng cổ phần so với bằng chứng công việc: + + + +## Đọc thêm {#further-reading} + +- [Triết lý thiết kế bằng chứng cổ phần của Vitalik](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) +- [Câu hỏi thường gặp về bằng chứng cổ phần của Vitalik](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) +- [Video "Giải thích đơn giản" về PoS và PoW](https://www.youtube.com/watch?v=M3EFi_POhps) diff --git a/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md new file mode 100644 index 00000000000..483f637d9a9 --- /dev/null +++ b/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -0,0 +1,91 @@ +--- +title: "Phần thưởng và hình phạt của Bằng chứng cổ phần" +description: "Tìm hiểu về các ưu đãi trong giao thức trong Ethereum bằng chứng cổ phần." +lang: vi +--- + +Ethereum được bảo mật bằng tiền mã hóa gốc của nó, ether (ETH). Các nhà khai thác nút muốn tham gia xác thực các khối và xác định phần đầu của chuỗi, hãy gửi ether vào [hợp đồng ký gửi](/staking/deposit-contract/) trên Ethereum. Sau đó, họ được trả bằng ether để chạy phần mềm trình xác thực nhằm kiểm tra tính hợp lệ của các khối mới nhận được qua mạng ngang hàng và áp dụng thuật toán lựa chọn phân nhánh để xác định phần đầu của chuỗi. + +Trình xác thực có hai vai trò chính: 1) kiểm tra các khối mới và “chứng thực” chúng nếu hợp lệ, 2) đề xuất các khối mới khi được chọn ngẫu nhiên từ tổng nhóm trình xác thực. Nếu trình xác thực không thực hiện một trong hai nhiệm vụ này khi được yêu cầu, họ sẽ bỏ lỡ khoản thanh toán bằng ether. Các trình xác thực đôi khi cũng được giao nhiệm vụ tổng hợp chữ ký và tham gia vào các ủy ban đồng bộ. + +Ngoài ra còn có một số hành động rất khó thực hiện một cách vô tình và biểu thị một số ý định độc hại, chẳng hạn như đề xuất nhiều khối cho cùng một slot hoặc chứng thực nhiều khối cho cùng một slot. Đây là những hành vi “có thể bị cắt giảm” dẫn đến việc trình xác thực bị đốt một lượng ether (lên đến 1 ETH) trước khi trình xác thực bị xóa khỏi mạng, quá trình này mất 36 ngày. Ether của trình xác thực bị cắt giảm sẽ dần dần cạn kiệt trong giai đoạn thoát, nhưng vào Ngày thứ 18, họ phải nhận một “hình phạt tương quan” lớn hơn khi có nhiều trình xác thực bị cắt giảm hơn trong cùng một khoảng thời gian. Do đó, cấu trúc khuyến khích của cơ chế đồng thuận sẽ trả công cho sự trung thực và trừng phạt những kẻ xấu. + +Tất cả các phần thưởng và hình phạt được áp dụng mỗi epoch một lần. + +Đọc tiếp để biết thêm chi tiết... + +## Phần thưởng và hình phạt {#rewards} + +### Phần thưởng {#rewards} + +Trình xác thực nhận được phần thưởng khi họ thực hiện các phiếu bầu nhất quán với phần lớn các trình xác thực khác, khi họ đề xuất các khối và khi họ tham gia vào các ủy ban đồng bộ. Giá trị của phần thưởng trong mỗi epoch được tính từ `base_reward`. Đây là đơn vị cơ sở mà các phần thưởng khác được tính toán. `base_reward` đại diện cho phần thưởng trung bình mà một trình xác thực nhận được trong điều kiện tối ưu cho mỗi epoch. Điều này được tính từ số dư hiệu dụng của trình xác thực và tổng số trình xác thực đang hoạt động như sau: + +``` +base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance)))) +``` + +trong đó `base_reward_factor` là 64, `base_rewards_per_epoch` là 4 và `sum(active balance)` là tổng số ether đã đặt cược trên tất cả các trình xác thực đang hoạt động. + +Điều này có nghĩa là phần thưởng cơ bản tỷ lệ thuận với số dư hiệu dụng của trình xác thực và tỷ lệ nghịch với số lượng trình xác thực trên mạng. Càng nhiều trình xác thực, tổng lượng phát hành càng lớn (dưới dạng `sqrt(N)` nhưng `base_reward` cho mỗi trình xác thực càng nhỏ (dưới dạng `1/sqrt(N)`). Các yếu tố này ảnh hưởng đến APR cho một nút đặt cược. Đọc lý do cho điều này trong [ghi chú của Vitalik](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards). + +Tổng phần thưởng sau đó được tính bằng tổng của năm thành phần, mỗi thành phần có một trọng số xác định mức độ mà mỗi thành phần thêm vào tổng phần thưởng. Các thành phần là: + +``` +1. bỏ phiếu nguồn: trình xác thực đã bỏ phiếu kịp thời cho điểm kiểm tra nguồn chính xác +2. bỏ phiếu mục tiêu: trình xác thực đã bỏ phiếu kịp thời cho điểm kiểm tra mục tiêu chính xác +3. bỏ phiếu đầu: trình xác thực đã bỏ phiếu kịp thời cho khối đầu chính xác +4. phần thưởng ủy ban đồng bộ: trình xác thực đã tham gia vào một ủy ban đồng bộ +5. phần thưởng người đề xuất: trình xác thực đã đề xuất một khối trong slot chính xác +``` + +Trọng số cho mỗi thành phần như sau: + +``` +TIMELY_SOURCE_WEIGHT uint64(14) +TIMELY_TARGET_WEIGHT uint64(26) +TIMELY_HEAD_WEIGHT uint64(14) +SYNC_REWARD_WEIGHT uint64(2) +PROPOSER_WEIGHT uint64(8) +``` + +Các trọng số này có tổng là 64. Phần thưởng được tính bằng tổng các trọng số áp dụng chia cho 64. Một trình xác thực đã thực hiện các phiếu bầu nguồn, mục tiêu và đầu đúng lúc, đề xuất một khối và tham gia vào ủy ban đồng bộ có thể nhận được `64/64 * base_reward == base_reward`. Tuy nhiên, một trình xác thực thường không phải là người đề xuất khối, vì vậy phần thưởng tối đa của họ là `64-8 /64 * base_reward == 7/8 * base_reward`. Các trình xác thực không phải là người đề xuất khối cũng không thuộc ủy ban đồng bộ có thể nhận được `64-8-2 / 64 * base_reward == 6.75/8 * base_reward`. + +Một phần thưởng bổ sung được thêm vào để khuyến khích các sự chứng thực nhanh chóng. Đây là `inclusion_delay_reward`. Giá trị này bằng `base_reward` nhân với `1/delay`, trong đó `delay` là số lượng slot phân tách đề xuất khối và sự chứng thực. Ví dụ: nếu sự chứng thực được gửi trong vòng một slot của đề xuất khối, người chứng thực sẽ nhận được `base_reward * 1/1 == base_reward`. Nếu sự chứng thực đến trong slot tiếp theo, người chứng thực sẽ nhận được `base_reward * 1/2`, v.v. + +Người đề xuất khối nhận `8 / 64 * base_reward` cho **mỗi sự chứng thực hợp lệ** có trong khối, vì vậy giá trị thực tế của phần thưởng sẽ thay đổi theo quy mô cùng số lượng trình xác thực chứng thực. Người đề xuất khối cũng có thể tăng phần thưởng của mình bằng cách bao gồm bằng chứng về hành vi sai trái của các trình xác thực khác trong khối được đề xuất của họ. Những phần thưởng này là “củ cà rốt” khuyến khích sự trung thực của trình xác thực. Một người đề xuất khối bao gồm hành vi phạt cắt giảm sẽ được thưởng bằng `slashed_validators_effective_balance / 512`. + +### Hình phạt {#penalties} + +Cho đến nay, chúng tôi đã xem xét các trình xác thực hoạt động hoàn hảo, nhưng còn các trình xác thực không bỏ phiếu cho đầu, nguồn và mục tiêu kịp thời hoặc làm như vậy một cách chậm chạp thì sao? + +Các hình phạt cho việc bỏ lỡ các phiếu bầu mục tiêu và nguồn bằng với phần thưởng mà người chứng thực sẽ nhận được nếu họ đã gửi chúng. Điều này có nghĩa là thay vì được cộng phần thưởng vào số dư của mình, họ sẽ bị trừ đi một giá trị tương đương từ số dư của mình. Không có hình phạt nào cho việc bỏ lỡ phiếu bầu đầu (tức là phiếu bầu đầu chỉ được thưởng, không bao giờ bị phạt). Không có hình phạt nào liên quan đến `inclusion_delay` - phần thưởng sẽ không được cộng vào số dư của trình xác thực. Cũng không có hình phạt nào cho việc không đề xuất được một khối. + +Đọc thêm về phần thưởng và hình phạt trong [thông số kỹ thuật đồng thuận](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md). Phần thưởng và hình phạt đã được điều chỉnh trong bản nâng cấp Bellatrix - hãy xem Danny Ryan và Vitalik thảo luận về điều này trong [video Peep an EIP](https://www.youtube.com/watch?v=iaAEGs1DMgQ). + +## Phạt cắt giảm {#slashing} + +Phạt cắt giảm là một hành động nghiêm trọng hơn dẫn đến việc loại bỏ một trình xác thực khỏi mạng và mất đi một phần ether đã đặt cược của họ. Có ba cách một trình xác thực có thể bị phạt cắt giảm, tất cả đều dẫn đến việc đề xuất hoặc chứng thực các khối không trung thực: + +- Bằng cách đề xuất và ký hai khối khác nhau cho cùng một slot +- Bằng cách chứng thực một khối "bao quanh" một khối khác (thay đổi lịch sử một cách hiệu quả) +- Bằng cách "bỏ phiếu kép" bằng cách chứng thực hai ứng cử viên cho cùng một khối + +Nếu những hành động này bị phát hiện, trình xác thực sẽ bị phạt cắt giảm. Điều này có nghĩa là 0,0078125 sẽ bị đốt ngay lập tức đối với một trình xác thực 32 ETH (thay đổi quy mô tuyến tính với số dư hoạt động), sau đó bắt đầu giai đoạn loại bỏ 36 ngày. Trong giai đoạn loại bỏ này, cổ phần của trình xác thực dần dần bị mất đi. Tại điểm giữa (Ngày thứ 18), một hình phạt bổ sung được áp dụng với mức độ thay đổi theo quy mô cùng tổng số ether đã đặt cược của tất cả các trình xác thực bị phạt cắt giảm trong 36 ngày trước sự kiện phạt cắt giảm. Điều này có nghĩa là khi càng nhiều trình xác thực bị phạt cắt giảm, mức độ phạt cắt giảm càng tăng. Mức phạt cắt giảm tối đa là toàn bộ số dư hiệu dụng của tất cả các trình xác thực bị phạt cắt giảm (tức là, nếu có nhiều trình xác thực bị phạt cắt giảm, họ có thể mất toàn bộ cổ phần của mình). Mặt khác, một sự kiện phạt cắt giảm đơn lẻ, riêng biệt chỉ đốt một phần nhỏ cổ phần của trình xác thực. Hình phạt giữa kỳ này thay đổi theo quy mô cùng số lượng trình xác thực bị phạt cắt giảm được gọi là "hình phạt tương quan". + +## Rò rỉ do không hoạt động {#inactivity-leak} + +Nếu lớp đồng thuận đã trải qua hơn bốn epoch mà không hoàn tất, một giao thức khẩn cấp được gọi là "rò rỉ do không hoạt động" sẽ được kích hoạt. Mục đích cuối cùng của việc rò rỉ do không hoạt động là tạo ra các điều kiện cần thiết để chuỗi phục hồi tính kết luận cuối cùng. Như đã giải thích ở trên, tính kết luận cuối cùng đòi hỏi đa số 2/3 tổng số ether đã đặt cược phải đồng ý về các điểm kiểm tra nguồn và mục tiêu. Nếu các trình xác thực đại diện cho hơn 1/3 tổng số trình xác thực ngoại tuyến hoặc không gửi các chứng thực chính xác thì không thể có đa số 2/3 để hoàn tất các điểm kiểm tra. Rò rỉ do không hoạt động cho phép cổ phần của các trình xác thực không hoạt động dần dần bị mất đi cho đến khi họ kiểm soát ít hơn 1/3 tổng số cổ phần, cho phép các trình xác thực đang hoạt động còn lại hoàn tất chuỗi. Tuy nhiên, dù nhóm trình xác thực không hoạt động lớn đến đâu, các trình xác thực đang hoạt động còn lại cuối cùng sẽ kiểm soát >2/3 cổ phần. Việc mất cổ phần là một động lực mạnh mẽ để các trình xác thực không hoạt động kích hoạt lại càng sớm càng tốt! Một kịch bản rò rỉ do không hoạt động đã xảy ra trên mạng thử nghiệm Medalla khi < 66% trình xác thực đang hoạt động có thể đi đến sự đồng thuận về phần đầu hiện tại của chuỗi khối. Rò rỉ do không hoạt động đã được kích hoạt và tính kết luận cuối cùng cuối cùng đã được lấy lại! + +Thiết kế phần thưởng, hình phạt và phạt cắt giảm của cơ chế đồng thuận khuyến khích các trình xác thực cá nhân hành xử đúng đắn. Tuy nhiên, từ những lựa chọn thiết kế này đã tạo ra một hệ thống khuyến khích mạnh mẽ việc phân phối đồng đều các trình xác thực trên nhiều máy khách và sẽ ngăn cản mạnh mẽ sự thống trị của một máy khách duy nhất. + +## Đọc thêm {#further-reading} + +- [Nâng cấp Ethereum: Lớp ưu đãi](https://eth2book.info/altair/part2/incentives) +- [Các ưu đãi trong giao thức Casper kết hợp của Ethereum](https://arxiv.org/pdf/1903.04205.pdf) +- [Thông số kỹ thuật có chú thích của Vitalik](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1) +- [Mẹo phòng chống phạt cắt giảm Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) +- [Phân tích hình phạt cắt giảm theo EIP-7251](https://ethresear.ch/t/slashing-penalty-analysis-eip-7251/16509) + +_Nguồn_ + +- _[https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/)_ diff --git a/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md b/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md new file mode 100644 index 00000000000..23a2b4043a3 --- /dev/null +++ b/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md @@ -0,0 +1,39 @@ +--- +title: "Chủ quan yếu kém" +description: "Giải thích về tính chủ quan yếu và vai trò của nó trong PoS Ethereum." +lang: vi +--- + +Tính chủ quan trong các chuỗi khối đề cập đến sự phụ thuộc vào thông tin xã hội để đồng thuận về trạng thái hiện tại. Có thể có nhiều phân nhánh hợp lệ được chọn từ đó theo thông tin thu thập được từ các máy ngang hàng khác trên mạng. Ngược lại là tính khách quan, đề cập đến các chuỗi chỉ có một chuỗi hợp lệ duy nhất mà tất cả các nút nhất thiết sẽ đồng thuận bằng cách áp dụng các quy tắc được mã hóa của chúng. Ngoài ra còn có một trạng thái thứ ba, được gọi là tính chủ quan yếu. Điều này đề cập đến một chuỗi có thể tiến triển một cách khách quan sau khi một số mầm mống thông tin ban đầu được truy xuất một cách xã hội. + +## Điều kiện tiên quyết {#prerequisites} + +Để hiểu trang này, trước tiên cần phải hiểu các nguyên tắc cơ bản của [bằng chứng cổ phần](/developers/docs/consensus-mechanisms/pos/). + +## Tính chủ quan yếu giải quyết những vấn đề gì? {#problems-ws-solves} + +Tính chủ quan vốn có trong các chuỗi khối bằng chứng cổ phần vì việc chọn chuỗi chính xác từ nhiều phân nhánh được thực hiện bằng cách đếm các phiếu bầu trong quá khứ. Điều này phơi bày chuỗi khối trước một số véc-tơ tấn công, bao gồm cả các cuộc tấn công tầm xa, theo đó các nút đã tham gia từ rất sớm trong chuỗi duy trì một phân nhánh thay thế mà chúng phát hành sau đó rất lâu để trục lợi. Ngoài ra, nếu 33% người xác thực rút cổ phần của họ nhưng vẫn tiếp tục chứng thực và tạo khối, họ có thể tạo ra một phân nhánh thay thế xung đột với chuỗi chính tắc. Các nút mới hoặc các nút đã ngoại tuyến trong một thời gian dài có thể không biết rằng những người xác thực tấn công này đã rút tiền của họ, vì vậy những kẻ tấn công có thể lừa họ đi theo một chuỗi không chính xác. Ethereum có thể giải quyết các véc-tơ tấn công này bằng cách áp đặt các ràng buộc làm giảm các khía cạnh chủ quan của cơ chế—và do đó là các giả định về sự tin cậy—xuống mức tối thiểu. + +## Các điểm kiểm tra tính chủ quan yếu {#ws-checkpoints} + +Tính chủ quan yếu được triển khai trong Ethereum bằng chứng cổ phần bằng cách sử dụng "các điểm kiểm tra tính chủ quan yếu". Đây là các gốc trạng thái mà tất cả các nút trên mạng đều đồng thuận thuộc về chuỗi chính tắc. Chúng phục vụ cùng mục đích "sự thật phổ quát" như các khối khởi nguyên, ngoại trừ việc chúng không nằm ở vị trí khởi nguyên trong chuỗi khối. Thuật toán lựa chọn phân nhánh tin tưởng rằng trạng thái chuỗi khối được xác định trong điểm kiểm tra đó là chính xác và nó xác minh chuỗi một cách độc lập và khách quan kể từ thời điểm đó trở đi. Các điểm kiểm tra hoạt động như "giới hạn hoàn nguyên" vì các khối nằm trước các điểm kiểm tra tính chủ quan yếu không thể bị thay đổi. Điều này làm suy yếu các cuộc tấn công tầm xa đơn giản bằng cách xác định các phân nhánh tầm xa là không hợp lệ như một phần của thiết kế cơ chế. Việc đảm bảo rằng các điểm kiểm tra tính chủ quan yếu được ngăn cách bởi một khoảng cách nhỏ hơn thời gian rút tiền của người xác thực đảm bảo rằng một người xác thực phân nhánh chuỗi sẽ bị phạt cắt giảm ít nhất một số tiền ngưỡng trước khi họ có thể rút cổ phần của mình và những người mới tham gia không thể bị lừa vào các phân nhánh không chính xác bởi những người xác thực đã rút cổ phần. + +## Sự khác biệt giữa các điểm kiểm tra tính chủ quan yếu và các khối đã hoàn tất {#difference-between-ws-and-finalized-blocks} + +Các khối đã hoàn tất và các điểm kiểm tra tính chủ quan yếu được các nút Ethereum xử lý khác nhau. Nếu một nút nhận biết được hai khối đã hoàn tất đang cạnh tranh nhau, thì nó sẽ bị giằng co giữa hai lựa chọn - nó không có cách nào để tự động xác định đâu là phân nhánh chính tắc. Đây là triệu chứng của sự cố đồng thuận. Ngược lại, một nút chỉ đơn giản là từ chối bất kỳ khối nào xung đột với điểm kiểm tra tính chủ quan yếu của nó. Từ góc nhìn của nút, điểm kiểm tra tính chủ quan yếu đại diện cho một sự thật tuyệt đối không thể bị phá vỡ bởi kiến thức mới từ các máy ngang hàng của nó. + +## Yếu đến mức nào? {#how-weak-is-weak} + +Khía cạnh chủ quan của bằng chứng cổ phần của Ethereum là yêu cầu một trạng thái gần đây (điểm kiểm tra tính chủ quan yếu) từ một nguồn đáng tin cậy để đồng bộ hóa. Rủi ro nhận được một điểm kiểm tra tính chủ quan yếu sai là rất thấp vì chúng có thể được kiểm tra đối chiếu với một số nguồn công khai độc lập như các trình duyệt khối hoặc nhiều nút. Tuy nhiên, luôn có một mức độ tin cậy nhất định được yêu cầu để chạy bất kỳ ứng dụng phần mềm nào, ví dụ, tin tưởng rằng các nhà phát triển phần mềm đã tạo ra phần mềm trung thực. + +Một điểm kiểm tra tính chủ quan yếu thậm chí có thể là một phần của phần mềm máy khách. Có thể cho rằng một kẻ tấn công có thể làm sai lệch điểm kiểm tra trong phần mềm và cũng có thể dễ dàng làm sai lệch chính phần mềm đó. Không có con đường kinh tế-mật mã thực sự nào để giải quyết vấn đề này, nhưng tác động của các nhà phát triển không đáng tin cậy được giảm thiểu trong Ethereum bằng cách có nhiều nhóm máy khách độc lập, mỗi nhóm xây dựng phần mềm tương đương bằng các ngôn ngữ khác nhau, tất cả đều có lợi ích cố hữu trong việc duy trì một chuỗi trung thực. Các trình duyệt khối cũng có thể cung cấp các điểm kiểm tra tính chủ quan yếu hoặc một cách để tham chiếu chéo các điểm kiểm tra thu được từ nơi khác với một nguồn bổ sung. + +Cuối cùng, các điểm kiểm tra có thể được yêu cầu từ các nút khác; có lẽ một người dùng Ethereum khác chạy một nút đầy đủ có thể cung cấp một điểm kiểm tra mà sau đó những người xác thực có thể xác minh với dữ liệu từ một trình duyệt khối. Nhìn chung, việc tin tưởng nhà cung cấp một điểm kiểm tra tính chủ quan yếu có thể được coi là có vấn đề tương tự như việc tin tưởng các nhà phát triển máy khách. Mức độ tin cậy tổng thể được yêu cầu là thấp. Điều quan trọng cần lưu ý là những cân nhắc này chỉ trở nên quan trọng trong trường hợp rất khó xảy ra là đa số người xác thực âm mưu tạo ra một phân nhánh thay thế của chuỗi khối. Trong bất kỳ trường hợp nào khác, chỉ có một chuỗi Ethereum để lựa chọn. + +## Đọc thêm {#further-reading} + +- [Tính chủ quan yếu trong Eth2](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2) +- [Vitalik: Tôi đã học cách yêu tính chủ quan yếu như thế nào](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) +- [Tính chủ quan yếu (tài liệu Teku)](https://docs.teku.consensys.io/concepts/weak-subjectivity) +- [Hướng dẫn về tính chủ quan yếu Giai đoạn 0](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/weak-subjectivity.md) +- [Phân tích tính chủ quan yếu trong Ethereum 2.0](https://github.com/runtimeverification/beacon-chain-verification/blob/master/weak-subjectivity/weak-subjectivity-analysis.pdf) diff --git a/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md b/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md new file mode 100644 index 00000000000..f5e5b2369b4 --- /dev/null +++ b/public/content/translations/vi/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md @@ -0,0 +1,64 @@ +--- +title: "Thông tin xác thực rút tiền" +description: "Giải thích về các loại thông tin xác thực rút tiền của trình xác thực (0x00, 0x01, 0x02) và ý nghĩa của chúng đối với người đặt cọc Ethereum." +lang: vi +--- + +Mỗi trình xác thực đều có một **thông tin xác thực rút tiền** để xác định cách thức và nơi ETH đã đặt cọc và phần thưởng của họ có thể được rút. Loại thông tin xác thực được biểu thị bằng byte đầu tiên: `0x00`, `0x01`, hoặc `0x02`. Việc hiểu các loại này rất quan trọng đối với các trình xác thực quản lý cổ phần của họ. + +## 0x00: Thông tin xác thực trước Shapella {#0x00-credentials} + +Loại `0x00` là định dạng thông tin xác thực rút tiền ban đầu có từ trước bản nâng cấp Shapella (tháng 4 năm 2023). Các trình xác thực có loại thông tin xác thực này không có địa chỉ rút tiền của lớp thực thi nào được đặt, nghĩa là tiền của họ vẫn bị khóa trên lớp đồng thuận. Nếu bạn vẫn còn thông tin xác thực `0x00`, bạn phải nâng cấp lên `0x01` hoặc `0x02` trước khi có thể nhận bất kỳ khoản rút tiền nào. + +## 0x01: Thông tin xác thực rút tiền cũ {#0x01-credentials} + +Loại `0x01` đã được giới thiệu cùng với bản nâng cấp Shapella và trở thành tiêu chuẩn cho các trình xác thực muốn đặt địa chỉ rút tiền của lớp thực thi. Với thông tin xác thực `0x01`: + +- Mọi số dư trên 32 ETH sẽ **tự động được quét** vào địa chỉ rút tiền của bạn +- Việc thoát hoàn toàn sẽ đi qua hàng chờ thoát tiêu chuẩn +- Phần thưởng trên 32 ETH không thể gộp lãi—chúng sẽ được quét định kỳ + +**Tại sao một số trình xác thực vẫn sử dụng 0x01:** Nó đơn giản và quen thuộc hơn. Nhiều trình xác thực đã gửi tiền sau Shapella và đã có loại này, và nó hoạt động tốt cho những ai muốn tự động rút số dư vượt mức. + +**Tại sao nó không được khuyến khích:** Với `0x01`, bạn mất khả năng gộp lãi phần thưởng trên 32 ETH. Mọi khoản dư thừa đều được quét tự động, điều này hạn chế tiềm năng kiếm tiền của trình xác thực của bạn và yêu cầu quản lý các khoản tiền đã rút một cách riêng biệt. + +## 0x02: Thông tin xác thực rút tiền gộp lãi {#0x02-credentials} + +Loại `0x02` đã được giới thiệu cùng với bản nâng cấp Pectra và là **lựa chọn được khuyến nghị** cho các trình xác thực ngày nay. Các trình xác thực có thông tin xác thực `0x02` đôi khi được gọi là "trình xác thực gộp lãi". + +Với thông tin xác thực `0x02`: + +- Phần thưởng trên 32 ETH được **gộp lãi** theo từng khoảng tăng 1 ETH cho đến số dư hiệu dụng tối đa là 2048 ETH +- Các khoản rút một phần phải được yêu cầu thủ công (việc quét tự động chỉ xảy ra trên ngưỡng 2048 ETH) +- Các trình xác thực có thể hợp nhất nhiều trình xác thực 32 ETH thành một trình xác thực có số dư cao hơn +- Việc thoát hoàn toàn vẫn được hỗ trợ thông qua hàng chờ thoát tiêu chuẩn + +Cả rút tiền một phần và hợp nhất đều có thể được thực hiện thông qua [Hành động của Trình xác thực Launchpad](https://launchpad.ethereum.org/en/validator-actions). + +**Tại sao các trình xác thực nên ưu tiên 0x02:** Nó mang lại hiệu quả sử dụng vốn tốt hơn thông qua việc gộp lãi, kiểm soát nhiều hơn thời điểm rút tiền và hỗ trợ hợp nhất trình xác thực. Đối với những người đặt cọc đơn lẻ tích lũy phần thưởng theo thời gian, điều này có nghĩa là số dư hiệu dụng của họ—và do đó là phần thưởng của họ—có thể tăng lên trên 32 ETH mà không cần can thiệp thủ công. + +**Quan trọng:** Một khi bạn đã chuyển đổi từ `0x01` sang `0x02`, bạn không thể hoàn nguyên lại. + +Để có hướng dẫn chi tiết về việc chuyển đổi sang thông tin xác thực Loại 2 và tính năng MaxEB, hãy xem [trang giải thích MaxEB](/roadmap/pectra/maxeb/). + +## Tôi nên chọn cái nào? {#what-should-i-pick} + +- **Trình xác thực mới:** Chọn `0x02`. Đó là tiêu chuẩn hiện đại với khả năng gộp lãi và tính linh hoạt tốt hơn. +- **Trình xác thực 0x01 hiện có:** Cân nhắc chuyển đổi sang `0x02` nếu bạn muốn phần thưởng được gộp lãi trên 32 ETH hoặc có kế hoạch hợp nhất các trình xác thực. +- **Trình xác thực 0x00 hiện có:** Nâng cấp ngay lập tức—bạn không thể rút tiền mà không cập nhật thông tin xác thực của mình. Trước tiên, bạn phải chuyển đổi sang `0x01`, sau đó bạn có thể chuyển đổi sang `0x02`. + +## Các công cụ để quản lý thông tin xác thực rút tiền {#withdrawal-credential-tools} + +Một số công cụ hỗ trợ việc lựa chọn hoặc chuyển đổi giữa các loại thông tin xác thực: + +- **[Bệ phóng Đặt cọc Ethereum](https://launchpad.ethereum.org/en/validator-actions)** - Công cụ chính thức cho việc gửi tiền và quản lý trình xác thực, bao gồm chuyển đổi và hợp nhất thông tin xác thực +- **[Trình quản lý Đặt cọc Pectra](https://pectrastaking.com)** - Giao diện người dùng web với hỗ trợ kết nối ví để chuyển đổi và hợp nhất +- **[Công cụ CLI Vận hành Trình xác thực Pectra](https://github.com/Luganodes/Pectra-Batch-Contract)** - Công cụ dòng lệnh để chuyển đổi hàng loạt +- **[Ethereal](https://github.com/wealdtech/ethereal)** - Công cụ CLI cho các hoạt động Ethereum bao gồm quản lý trình xác thực + +Để có danh sách đầy đủ các công cụ hợp nhất và hướng dẫn chuyển đổi chi tiết, hãy xem [bộ công cụ hợp nhất MaxEB](/roadmap/pectra/maxeb/#consolidation-tooling). + +## Đọc thêm {#further-reading} + +- [Các khóa trong Ethereum bằng chứng cổ phần](/developers/docs/consensus-mechanisms/pos/keys/) - Tìm hiểu về các khóa của trình xác thực và cách chúng liên quan đến thông tin xác thực rút tiền +- [MaxEB](/roadmap/pectra/maxeb/) - Hướng dẫn chi tiết về bản nâng cấp Pectra và tính năng số dư hiệu dụng tối đa diff --git a/public/content/translations/vi/developers/docs/consensus-mechanisms/pow/index.md b/public/content/translations/vi/developers/docs/consensus-mechanisms/pow/index.md new file mode 100644 index 00000000000..e2f8578f1a5 --- /dev/null +++ b/public/content/translations/vi/developers/docs/consensus-mechanisms/pow/index.md @@ -0,0 +1,114 @@ +--- +title: "Bằng chứng công việc (PoW)" +description: "Giải thích về giao thức đồng thuận bằng chứng công việc và vai trò của nó trong Ethereum." +lang: vi +--- + +Mạng Ethereum bắt đầu bằng cách sử dụng một cơ chế đồng thuận có tên là **[Bằng chứng công việc (PoW)](/developers/docs/consensus-mechanisms/pow)**. Điều này cho phép các nút của mạng lưới Ethereum đồng thuận về trạng thái của tất cả các thông tin được ghi lại trên chuỗi khối Ethereum và ngăn chặn một số loại tấn công kinh tế nhất định. Tuy nhiên, Ethereum đã ngừng sử dụng bằng chứng công việc vào năm 2022 và thay vào đó bắt đầu sử dụng [bằng chứng cổ phần](/developers/docs/consensus-mechanisms/pos). + + + + + + Chứng chỉ công việc hiện đã bị loại bỏ. Ethereum không còn sử dụng bằng chứng công việc như một phần của cơ chế đồng thuận nữa. Thay vào đó, nó sử dụng bằng chứng cổ phần. Đọc thêm về [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) và [đặt cược](/staking/). + + + + +## Điều kiện tiên quyết {#prerequisites} + +Để hiểu rõ hơn về trang này, chúng tôi khuyên bạn nên đọc trước về [các giao dịch](/developers/docs/transactions/), [các khối](/developers/docs/blocks/) và [các cơ chế đồng thuận](/developers/docs/consensus-mechanisms/). + +## Bằng cứng công việc (PoW) là gì? {#what-is-pow} + +Sự đồng thuận Nakamoto, vốn sử dụng bằng chứng công việc, là cơ chế từng cho phép mạng Ethereum phi tập trung đạt được sự đồng thuận (tức là mọi nút đều đồng ý) về những việc như số dư tài khoản và thứ tự các giao dịch. Điều này ngăn người dùng "chi tiêu hai lần" số tiền của họ và đảm bảo rằng chuỗi Ethereum trở nên vô cùng khó bị tấn công hoặc thao túng. Các thuộc tính bảo mật này hiện đến từ bằng chứng cổ phần, sử dụng cơ chế đồng thuận được gọi là [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/). + +## Bằng chứng công việc và khai thác {#pow-and-mining} + +Chứng chỉ công việc là thuật toán nền tảng xác định độ khó và các quy tắc cho công việc mà các thợ đào thực hiện trên các chuỗi khối sử dụng cơ chế Chứng chỉ công việc. Khai thác chính là bản thân “công việc” đó. Đó là hành động thêm các khối hợp lệ vào chuỗi. Điều này quan trọng vì độ dài của chuỗi giúp mạng lưới xác định đúng nhánh của chuỗi khối. Càng nhiều “công việc” được thực hiện, chuỗi càng dài, số khối càng cao, mạng lưới càng chắc chắn về trạng thái hiện tại của mọi thứ. + +[Thông tin thêm về khai thác](/developers/docs/consensus-mechanisms/pow/mining/) + +## Cơ chế Chứng chỉ công việc của Ethereum hoạt động như thế nào? {#how-it-works} + +Các giao dịch trên Ethereum được xử lý thành các khối. Trong Ethereum sử dụng cơ chế Chứng chỉ công việc hiện đã bị loại bỏ, mỗi khối chứa: + +- khối độ khó - Ví dụ: 3.324.092.183.262.715 +- mixHash – ví dụ: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29` +- nonce – ví dụ: `0xd3ee432b4fb3d26b` + +Dữ liệu khối này liên quan trực tiếp đến bằng chứng công việc. + +### Công việc trong bằng chứng công việc {#the-work} + +Giao thức bằng chứng công việc, Ethash, yêu cầu các thợ đào phải trải qua một cuộc chạy đua thử và sai căng thẳng để tìm nonce cho một khối. Chỉ các khối có chuỗi số ngẫu nhiên hợp lệ mới có thể được thêm vào chuỗi. + +Khi chạy đua để tạo một khối, thợ khai thác lặp đi lặp lại một bộ dữ liệu, chỉ có thể thu được bằng cách tải xuống và chạy toàn bộ chuỗi (như một thợ khai thác thực hiện), qua một hàm toán học. Bộ dữ liệu này được sử dụng để tạo ra một giá trị hàm băm thấp hơn mức mục tiêu do độ khó của khối quyết định. Cách tốt nhất để thực hiện việc này là thông qua phương pháp thử và sai. + +Độ khó xác định mục tiêu cho giá trị băm. Mục tiêu càng thấp, tập hợp các giá trị băm hợp lệ càng nhỏ. Một khi được tạo ra, điều này trở nên cực kỳ dễ dàng để các thợ đào và các ứng dụng khác xác minh. Ngay cả khi chỉ một giao dịch thay đổi, giá trị băm sẽ hoàn toàn khác, báo hiệu gian lận. + +Băm giúp dễ dàng phát hiện gian lận. Nhưng Chứng chỉ công việc như một quá trình cũng là rào cản lớn ngăn việc tấn công chuỗi. + +### Bằng chứng công việc và bảo mật {#security} + +Các thợ đào được khuyến khích thực hiện công việc này trên chuỗi Ethereum chính. Có rất ít động lực để một nhóm thợ đào bắt đầu chuỗi riêng của họ - vì điều đó sẽ làm suy yếu hệ thống. Chuỗi khối dựa vào việc có một trạng thái duy nhất làm nguồn tin cậy. + +Mục tiêu của bằng chứng công việc là mở rộng chuỗi. Chuỗi dài nhất được tin tưởng là hợp lệ nhất vì nó có nhiều công việc tính toán nhất để tạo ra nó. Trong hệ thống PoW của Ethereum, gần như không thể tạo các khối mới để xóa giao dịch, tạo giao dịch giả, hoặc duy trì một chuỗi thứ hai. Điều này là vì một thợ khai thác ác ý sẽ phải luôn giải được chuỗi số ngẫu nhiên của khối nhanh hơn tất cả mọi người khác. + +Để liên tục tạo các khối hợp lệ nhưng ác ý, một thợ khai thác ác ý sẽ cần hơn 51% sức mạnh khai thác của mạng để vượt qua tất cả những người khác. Lượng “công việc” đó đòi hỏi rất nhiều sức mạnh tính toán tốn kém và năng lượng tiêu thụ có thể còn vượt quá lợi ích đạt được từ một cuộc tấn công. + +### Kinh tế học bằng chứng công việc {#economics} + +Chứng chỉ công việc cũng chịu trách nhiệm phát hành tiền mới vào hệ thống và khuyến khích các thợ khai thác thực hiện công việc. + +Kể từ [bản nâng cấp Constantinople](/ethereum-forks/#constantinople), các thợ đào tạo thành công một khối đã được thưởng hai ETH mới được đúc và một phần phí giao dịch. Các khối ommer cũng được bồi thường 1,75 ETH. Khối ommer là các khối hợp lệ được một thợ khai thác tạo ra gần như cùng lúc với thợ khai thác khác tạo khối chính thức, và cuối cùng khối chính thức được xác định dựa trên chuỗi nào được xây dựng tiếp trước. Các khối ommer thường xảy ra do độ trễ mạng. + +## Tính kết luận cuối cùng {#finality} + +Một giao dịch có “Tính kết luận cuối cùng” trên Ethereum khi nó là một phần của khối không thể thay đổi. + +Vì các thợ đào làm việc theo cách phi tập trung, hai khối hợp lệ có thể được khai thác cùng lúc. Điều này tạo ra một phân nhánh tạm thời. Cuối cùng, một trong các chuỗi này trở thành chuỗi được chấp nhận sau khi các khối tiếp theo được khai thác và thêm vào, làm cho nó dài hơn. + +Để làm phức tạp thêm mọi thứ, các giao dịch bị từ chối trên phân nhánh tạm thời có thể không được đưa vào chuỗi được chấp nhận. Điều này có nghĩa là nó có thể bị đảo ngược. Do đó, tính kết luận cuối cùng đề cập đến khoảng thời gian bạn nên chờ trước khi xem xét một giao dịch không thể đảo ngược. Với Ethereum bằng chứng công việc trước đây, càng có nhiều khối được khai thác trên một khối `N` cụ thể, thì độ tin cậy rằng các giao dịch trong `N` đã thành công và sẽ không bị đảo ngược càng cao. Hiện nay, với cơ chế bằng chứng cổ phần, tính cuối cùng của một khối là một đặc tính rõ ràng, thay vì mang tính xác suất. + +## Mức tiêu thụ năng lượng của bằng chứng công việc {#energy} + +Một trong những chỉ trích chính về chứng chỉ làm việc là lượng năng lượng cần thiết để giữ an toàn cho mạng lưới. Để duy trì bảo mật và tính phi tập trung, Ethereum khi sử dụng bằng chứng công việc đã tiêu thụ một lượng lớn năng lượng. Ngay trước khi chuyển sang bằng chứng cổ phần, các thợ đào Ethereum đã tiêu thụ tổng cộng khoảng 70 TWh/năm (tương đương mức tiêu thụ của Cộng hòa Séc - theo [digiconomist](https://digiconomist.net/) vào ngày 18 tháng 7 năm 2022). + +## Ưu và nhược điểm {#pros-and-cons} + +| Ưu điểm | Nhược điểm | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Bằng chứng công việc là trung lập. Bạn không cần ETH để bắt đầu và phần thưởng khối sẽ cho bạn từ 0ETH đến một số dư số dương. Với [bằng chứng cổ phần](/developers/docs/consensus-mechanisms/pos/), bạn cần có ETH để bắt đầu. | Bằng chứng công việc tiêu thụ quá nhiều năng lượng, gây hại cho môi trường. | +| Bằng chứng công việc là một cơ chế đồng thuận kiểm thử, giúp Bitcoin và Ethereum duy trì tính bảo mật và tính phi tập trung trong nhiều năm. | Nếu bạn muốn khai thác, bạn cần thiết bị chuyên dụng đến mức việc bắt đầu là một khoản đầu tư lớn. | +| So với bằng chứng cổ phần, nó tương đối dễ triển khai. | Do nhu cầu tính toán ngày càng tăng, các nhóm khai thác có thể chiếm ưu thế trong việc khai thác, dẫn đến tập trung hóa và rủi ro bảo mật. | + +## So sánh với bằng chứng cổ phần {#compared-to-pos} + +Ở cấp độ cao, bằng chứng cổ phần có cùng mục tiêu cuối cùng như bằng chứng công việc: giúp mạng phi tập trung đạt được sự đồng thuận một cách an toàn. Nhưng nó có một số khác biệt về quy trình và nhân sự: + +- Bằng chứng công việc thay thế tầm quan trọng của sức mạnh tính toán bằng ETH đã được đặt cọc. +- Chứng chỉ gửi thay thế các thợ khai thác bằng các người xác thực. Các người xác thực đặt cọc ETH của họ để kích hoạt khả năng tạo các khối mới. +- Các người xác thực không cạnh tranh để tạo khối; thay vào đó, họ được chọn ngẫu nhiên bởi một thuật toán. +- Tính kết luận cuối cùng rõ ràng hơn: tại các điểm kiểm tra nhất định, nếu 2/3 trình xác thực đồng ý về trạng thái của khối, khối đó được coi là cuối cùng. Trình xác thực phải đặt cược toàn bộ tiền đặt cược của họ vào điều này, vì vậy nếu họ cố gắng thông đồng, họ sẽ mất toàn bộ tiền đặt cược. + +[Thông tin thêm về bằng chứng cổ phần](/developers/docs/consensus-mechanisms/pos/) + +## Tìm hiểu thêm từ video trực quan? Người học qua hình ảnh {#visual-learner} + + + +## Đọc thêm {#further-reading} + +- [Tấn công đa số](https://en.bitcoin.it/wiki/Majority_attack) +- [Về tính hoàn tất của quyết toán](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) + +### Video {#videos} + +- [Giải thích kỹ thuật về các giao thức bằng chứng công việc](https://youtu.be/9V1bipPkCTU) + +## Các chủ đề liên quan {#related-topics} + +- [Khai thác](/developers/docs/consensus-mechanisms/pow/mining/) +- [Bằng chứng cổ phần](/developers/docs/consensus-mechanisms/pos/) +- [Bằng chứng ủy quyền](/developers/docs/consensus-mechanisms/poa/) diff --git a/public/content/translations/vi/developers/docs/consensus-mechanisms/pow/mining/index.md b/public/content/translations/vi/developers/docs/consensus-mechanisms/pow/mining/index.md new file mode 100644 index 00000000000..fbb58f48618 --- /dev/null +++ b/public/content/translations/vi/developers/docs/consensus-mechanisms/pow/mining/index.md @@ -0,0 +1,86 @@ +--- +title: "Khai thác" +description: "Giải thích về cách hoạt động của việc khai thác trên Ethereum." +lang: vi +--- + + + + + +Bằng chứng làm việc không còn là cơ chế đồng thuận nền tảng của Ethereum, nghĩa là việc khai thác đã bị tắt. Thay vào đó, Ethereum được bảo mật bởi các trình xác thực đặt cọc ETH. Bạn có thể bắt đầu đặt cọc ETH của mình ngay từ hôm nay. Đọc thêm về sự kiện hợp nhất, Bằng chứng cổ phần và Cổ phần. Trang này chỉ nhằm mục đích tham khảo lịch sử. + + + + +## Điều kiện tiên quyết {#prerequisites} + +Để hiểu rõ hơn về trang này, chúng tôi khuyên bạn nên đọc trước về [các giao dịch](/developers/docs/transactions/), [các khối](/developers/docs/blocks/) và [bằng chứng công việc](/developers/docs/consensus-mechanisms/pow/). + +## Đào Ethereum là gì? {#what-is-ethereum-mining} + +Khai thác là quá trình tạo ra một khối giao dịch để thêm vào blockchain Ethereum trong kiến trúc bằng chứng làm việc của Ethereum, hiện đã bị loại bỏ. + +Từ mining bắt nguồn từ phép ẩn dụ vàng trong bối cảnh tiền điện tử. Vàng hay các kim loại quý thì khan hiếm, tương tự, các token số cũng khan hiếm, và cách duy nhất để tăng tổng lượng trong hệ thống Bằng chứng làm việc là thông qua khai thác. Trong Ethereum sử dụng bằng chứng làm việc, cách duy nhất để phát hành token là thông qua khai thác. Tuy nhiên, khác với vàng hay các kim loại quý, khai thác Ethereum còn là phương thức để bảo mật mạng lưới bằng cách tạo, xác minh, công bố và truyền tải các khối lên blockchain. + +Khai thác Ethers = Bảo mật mạng lưới + +Khai thác là mạch sống của bất kỳ blockchain nào sử dụng cơ chế Bằng chứng làm việc. Các thợ đào Ethereum – những máy tính chạy phần mềm – đã sử dụng thời gian và sức mạnh tính toán của mình để xử lý giao dịch và tạo khối trước khi Ethereum chuyển sang cơ chế Bằng chứng cổ phần. + +## Tại sao lại có các thợ đào? {#why-do-miners-exist} + +Trong các hệ thống phi tập trung như Ethereum, chúng ta cần đảm bảo rằng tất cả mọi người đồng thuận về thứ tự các giao dịch. Các thợ đào trợ giúp điều này xảy ra bằng cách giải các bài toán tính toán phức tạp để tạo khối, đồng thời bảo vệ mạng lưới khỏi các cuộc tấn công. + +[Thông tin thêm về bằng chứng công việc](/developers/docs/consensus-mechanisms/pow/) + +Trước đây, bất kỳ ai cũng có thể khai thác trên mạng lưới Ethereum bằng máy tính của mình. Tuy nhiên, không phải ai cũng có thể khai thác Ether (ETH) một cách có lợi nhuận. Trong hầu hết các trường hợp, các thợ đào phải mua phần cứng máy tính chuyên dụng và có nguồn năng lượng giá rẻ. Các máy tính thông thường khó có thể kiếm đủ phần thưởng khối để bù đắp chi phí khai thác liên quan. + +### Chi phí khai thác {#cost-of-mining} + +- Chi phí tiềm ẩn cho phần cứng cần thiết để xây dựng và vận hành một dàn khai thác +- Chi phí điện để cung cấp năng lượng cho dàn khai thác +- Nếu bạn khai thác trong một bể, các bể này thường tính một mức phí cố định theo phần trăm trên mỗi khối mà bể tạo ra +- Chi phí tiềm ẩn cho thiết bị hỗ trợ dàn khai thác (quạt thông gió, giám sát năng lượng, hệ thống điện, v.v.) + +Để tìm hiểu thêm về lợi nhuận khai thác, hãy sử dụng công cụ tính toán khai thác, chẳng hạn như công cụ do [Etherscan](https://etherscan.io/ether-mining-calculator) cung cấp. + +## Cách các giao dịch Ethereum đã được khai thác {#how-ethereum-transactions-were-mined} + +Phần sau đây cung cấp tổng quan về cách các giao dịch được khai thác trên Ethereum theo cơ chế Bằng chứng làm việc. Mô tả tương tự về quy trình này cho bằng chứng cổ phần của Ethereum có thể được tìm thấy [tại đây](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos). + +1. Một người dùng viết và ký một yêu cầu [giao dịch](/developers/docs/transactions/) bằng khóa riêng tư của một [tài khoản](/developers/docs/accounts/) nào đó. +2. Người dùng phát tán yêu cầu giao dịch đến toàn bộ mạng Ethereum từ một [nút](/developers/docs/nodes-and-clients/) nào đó. +3. Khi nhận được thông tin về yêu cầu giao dịch mới, mỗi nút trong mạng Ethereum sẽ thêm yêu cầu đó vào bộ nhớ tạm cục bộ, là danh sách tất cả các yêu cầu giao dịch mà chúng biết nhưng chưa được ghi vào chuỗi khối dưới dạng một khối. +4. Tại một thời điểm nào đó, một nút khai thác tổng hợp vài chục hoặc hàng trăm yêu cầu giao dịch thành một [khối](/developers/docs/blocks/) tiềm năng, theo cách tối đa hóa [phí giao dịch](/developers/docs/gas/) mà họ kiếm được trong khi vẫn ở dưới giới hạn gas của khối. Nút khai thác sau đó sẽ là: + 1. Xác minh tính hợp lệ của từng yêu cầu giao dịch (tức là không ai đang cố gắng chuyển ether ra khỏi một tài khoản mà họ chưa ký, yêu cầu không bị sai định dạng, v.v.), sau đó thực thi mã của yêu cầu, làm thay đổi trạng thái bản sao cục bộ của Máy chủ ảo Ethereum của họ. Thợ đào sẽ nhận phí giao dịch của mỗi yêu cầu giao dịch đó vào tài khoản của chính họ. + 2. Bắt đầu quá trình tạo chứng chỉ hợp lệ cho khối tiềm năng, sau khi tất cả các yêu cầu giao dịch trong khối đã được xác minh và thực thi trên bản sao Máy chủ ảo Ethereum cục bộ. +5. Cuối cùng, một thợ đào sẽ hoàn tất việc tạo chứng chỉ cho một khối, trong đó bao gồm yêu cầu giao dịch cụ thể của chúng ta. Sau đó, thợ khai thác phát tán khối đã hoàn tất, trong đó bao gồm chứng chỉ và một giá trị kiểm tra của trạng thái Máy chủ ảo Ethereum mới được khai báo. +6. Các nút khác nhận được thông tin về khối mới. Họ xác minh chứng chỉ, tự thực thi tất cả các giao dịch trong khối (bao gồm cả giao dịch ban đầu do người dùng của chúng ta phát tán), và kiểm tra xem giá trị kiểm tra của trạng thái Máy chủ ảo Ethereum mới sau khi thực thi tất cả giao dịch có khớp với giá trị kiểm tra của trạng thái do khối của Thợ đào khai báo hay không. Chỉ sau đó, các nút này mới thêm khối này vào cuối chuỗi blockchain của họ và chấp nhận trạng thái Máy chủ ảo Ethereum mới là trạng thái chính thức. +7. Mỗi nút sẽ xóa tất cả các giao dịch trong khối mới khỏi bộ nhớ tạm cục bộ của mình, nơi lưu trữ các yêu cầu giao dịch chưa được thực hiện. +8. Các nút mới tham gia mạng sẽ tải xuống tất cả các khối theo thứ tự, bao gồm cả khối chứa giao dịch mà chúng ta quan tâm. Chúng khởi tạo một bản sao Máy chủ ảo Ethereum cục bộ (bắt đầu từ trạng thái trống), sau đó thực hiện quá trình thực thi mọi giao dịch trong từng khối trên bản sao Máy chủ ảo Ethereum cục bộ của mình, đồng thời kiểm tra giá trị kiểm tra trạng thái ở mỗi khối trong quá trình này. + +Mỗi giao dịch chỉ được khai thác một lần (được đưa vào khối mới và truyền đi lần đầu), nhưng lại được thực thi và xác minh bởi mọi người tham gia trong quá trình cập nhật trạng thái Máy chủ ảo Ethereum chính thức. Điều này nhấn mạnh một trong những phương châm cốt lõi của chuỗi khối: **Đừng tin, hãy xác minh**. + +## Các khối Ommer (chú) {#ommer-blocks} + +Khai thác khối trên cơ chế Bằng chứng công việc mang tính xác suất, nghĩa là đôi khi hai khối hợp lệ được công bố cùng lúc do độ trễ mạng. Trong trường hợp này, giao thức phải xác định chuỗi dài nhất (và do đó là chuỗi "hợp lệ" nhất) đồng thời đảm bảo công bằng cho các thợ khai thác bằng cách phần thưởng một phần cho khối hợp lệ nhưng không được đưa vào chuỗi. Điều này khuyến khích việc phân quyền hóa mạng hơn nữa, vì các thợ đào nhỏ hơn, những người có thể phải đối mặt với độ trễ cao hơn, vẫn có thể tạo ra lợi nhuận thông qua phần thưởng khối [ommer](/glossary/#ommer). + +Thuật ngữ "ommer" là cách gọi trung lập về giới tính được ưu tiên cho khối anh/chị/em của khối cha, nhưng đôi khi cũng được gọi là "chú". **Kể từ khi Ethereum chuyển sang bằng chứng cổ phần, các khối ommer không còn được khai thác nữa** vì chỉ có một người đề xuất được bầu trong mỗi slot. Bạn có thể thấy sự thay đổi này bằng cách xem [biểu đồ lịch sử](https://ycharts.com/indicators/ethereum_uncle_rate) của các khối ommer đã được khai thác. + +## Bản demo trực quan {#a-visual-demo} + +Hãy theo dõi Austin hướng dẫn bạn về việc khai thác và chuỗi khỗi proof of work. + + + +## Thuật toán khai thác {#mining-algorithm} + +Mạng chính Ethereum chỉ từng sử dụng một thuật toán khai thác - ['Ethash'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/). Ethash là thuật toán kế thừa của thuật toán R&D ban đầu có tên là ['Dagger-Hashimoto'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/). + +[Tìm hiểu thêm về các thuật toán khai thác](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/). + +## Các chủ đề liên quan {#related-topics} + +- [Gas](/developers/docs/gas/) +- [Máy chủ ảo Ethereum](/developers/docs/evm/) +- [Bằng chứng công việc](/developers/docs/consensus-mechanisms/pow/) diff --git a/public/content/translations/vi/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md b/public/content/translations/vi/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md new file mode 100644 index 00000000000..a092468ebcf --- /dev/null +++ b/public/content/translations/vi/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md @@ -0,0 +1,330 @@ +--- +title: Dagger-Hashimoto +description: "Một cái nhìn chi tiết về thuật toán Dagger-Hashimoto." +lang: vi +--- + +Dagger-Hashimoto là bản triển khai nghiên cứu và đặc tả ban đầu cho thuật toán khai thác của Ethereum. Dagger-Hashimoto đã được thay thế bằng [Ethash](#ethash). Hoạt động khai thác đã bị tắt hoàn toàn tại [The Merge](/roadmap/merge/) vào ngày 15 tháng 9 năm 2022. Kể từ đó, Ethereum đã được bảo mật bằng cơ chế [bằng chứng cổ phần](/developers/docs/consensus-mechanisms/pos). Trang này mang tính chất lịch sử - thông tin ở đây không còn phù hợp với Ethereum sau The Merge. + +## Điều kiện tiên quyết {#prerequisites} + +Để hiểu rõ hơn về trang này, chúng tôi khuyên bạn nên đọc trước về [sự đồng thuận bằng chứng công việc](/developers/docs/consensus-mechanisms/pow), [khai thác](/developers/docs/consensus-mechanisms/pow/mining) và [các thuật toán khai thác](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms). + +## Dagger-Hashimoto {#dagger-hashimoto} + +Dagger-Hashimoto nhằm đáp ứng hai mục tiêu: + +1. **Kháng ASIC**: lợi ích từ việc tạo ra phần cứng chuyên dụng cho thuật toán phải nhỏ nhất có thể +2. **Khả năng xác minh của ứng dụng nhẹ**: một khối phải có thể được xác minh hiệu quả bởi một ứng dụng nhẹ. + +Với một sửa đổi bổ sung, chúng tôi cũng chỉ định cách thực hiện mục tiêu thứ ba nếu muốn, nhưng phải trả giá bằng sự phức tạp tăng thêm: + +**Lưu trữ toàn bộ chuỗi**: việc khai thác phải yêu cầu lưu trữ toàn bộ trạng thái chuỗi khối (do cấu trúc bất thường của cây trạng thái Ethereum, chúng tôi dự đoán rằng có thể thực hiện một số cắt tỉa, đặc biệt là đối với một số hợp đồng thường được sử dụng, nhưng chúng tôi muốn giảm thiểu điều này). + +## Tạo DAG {#dag-generation} + +Mã cho thuật toán sẽ được định nghĩa bằng Python bên dưới. Đầu tiên, chúng tôi cung cấp `encode_int` để sắp xếp các số nguyên không dấu có độ chính xác cụ thể thành các chuỗi. Nghịch đảo của nó cũng được đưa ra: + +```python +NUM_BITS = 512 + +def encode_int(x): + "Mã hóa một số nguyên x thành một chuỗi gồm 64 ký tự bằng cách sử dụng lược đồ big-endian" + o = '' + for _ in range(NUM_BITS / 8): + o = chr(x % 256) + o + x //= 256 + return o + +def decode_int(s): + "Giải mã một số nguyên x từ một chuỗi bằng cách sử dụng lược đồ big-endian" + x = 0 + for c in s: + x *= 256 + x += ord(c) + return x +``` + +Tiếp theo, chúng tôi giả định rằng `sha3` là một hàm nhận một số nguyên và xuất ra một số nguyên, và `dbl_sha3` là một hàm double-sha3; nếu chuyển đổi mã tham chiếu này thành một bản triển khai, hãy sử dụng: + +```python +from pyethereum import utils +def sha3(x): + if isinstance(x, (int, long)): + x = encode_int(x) + return decode_int(utils.sha3(x)) + +def dbl_sha3(x): + if isinstance(x, (int, long)): + x = encode_int(x) + return decode_int(utils.sha3(utils.sha3(x))) +``` + +### Các tham số {#parameters} + +Các tham số được sử dụng cho thuật toán là: + +```python +SAFE_PRIME_512 = 2**512 - 38117 # Số nguyên tố an toàn lớn nhất nhỏ hơn 2**512 + +params = { + "n": 4000055296 * 8 // NUM_BITS, # Kích thước của bộ dữ liệu (4 Gigabyte); PHẢI LÀ BỘI SỐ CỦA 65536 + "n_inc": 65536, # Gia số trong giá trị của n mỗi kỳ; PHẢI LÀ BỘI SỐ CỦA 65536 + # với epochtime=20000 cho tốc độ tăng trưởng 882 MB mỗi năm + "cache_size": 2500, # Kích thước bộ nhớ đệm của ứng dụng nhẹ (có thể được chọn bởi ứng dụng nhẹ + # ; không thuộc đặc tả của thuật toán) + "diff": 2**14, # Độ khó (được điều chỉnh trong quá trình đánh giá khối) + "epochtime": 100000, # Độ dài của một epoch trong các khối (tần suất bộ dữ liệu được cập nhật) + "k": 1, # Số lượng nút mẹ của một nút + "w": w, # Được sử dụng để băm lũy thừa theo mô-đun + "accesses": 200, # Số lần truy cập bộ dữ liệu trong quá trình hashimoto + "P": SAFE_PRIME_512 # Số nguyên tố an toàn để băm và tạo số ngẫu nhiên +} +``` + +`P` trong trường hợp này là một số nguyên tố được chọn sao cho `log₂(P)` nhỏ hơn 512 một chút, tương ứng với 512 bit mà chúng ta đã sử dụng để biểu diễn các con số của mình. Lưu ý rằng chỉ có nửa sau của DAG thực sự cần được lưu trữ, vì vậy yêu cầu RAM trên thực tế bắt đầu ở mức 1 GB và tăng 441 MB mỗi năm. + +### Xây dựng đồ thị Dagger {#dagger-graph-building} + +Nguyên hàm xây dựng đồ thị dagger được định nghĩa như sau: + +```python +def produce_dag(params, seed, length): + P = params["P"] + picker = init = pow(sha3(seed), params["w"], P) + o = [init] + for i in range(1, length): + x = picker = (picker * init) % P + for _ in range(params["k"]): + x ^= o[x % i] + o.append(pow(x, params["w"], P)) + return o +``` + +Về cơ bản, nó bắt đầu một đồ thị dưới dạng một nút duy nhất, `sha3(seed)`, và từ đó bắt đầu tuần tự thêm các nút khác dựa trên các nút ngẫu nhiên trước đó. Khi một nút mới được tạo, một lũy thừa theo mô-đun của seed được tính toán để chọn ngẫu nhiên một số chỉ số nhỏ hơn `i` (sử dụng `x % i` ở trên), và các giá trị của các nút tại các chỉ số đó được sử dụng trong một phép tính để tạo ra một giá trị mới cho `x`, sau đó được đưa vào một hàm bằng chứng công việc nhỏ (dựa trên XOR) để cuối cùng tạo ra giá trị của đồ thị tại chỉ số `i`. Lý do đằng sau thiết kế đặc biệt này là để buộc truy cập tuần tự vào DAG; giá trị tiếp theo của DAG sẽ được truy cập không thể được xác định cho đến khi giá trị hiện tại được biết. Cuối cùng, lũy thừa theo mô-đun sẽ băm kết quả sâu hơn nữa. + +Thuật toán này dựa trên một số kết quả từ lý thuyết số. Xem phụ lục bên dưới để thảo luận. + +## Đánh giá ứng dụng nhẹ {#light-client-evaluation} + +Việc xây dựng đồ thị ở trên nhằm mục đích cho phép mỗi nút trong đồ thị được tái tạo bằng cách tính toán một cây con chỉ gồm một số lượng nhỏ các nút và chỉ yêu cầu một lượng nhỏ bộ nhớ phụ. Lưu ý rằng với k=1, cây con chỉ là một chuỗi các giá trị đi lên đến phần tử đầu tiên trong DAG. + +Hàm tính toán của ứng dụng nhẹ cho DAG hoạt động như sau: + +```python +def quick_calc(params, seed, p): + w, P = params["w"], params["P"] + cache = {} + + def quick_calc_cached(p): + if p in cache: + pass + elif p == 0: + cache[p] = pow(sha3(seed), w, P) + else: + x = pow(sha3(seed), (p + 1) * w, P) + for _ in range(params["k"]): + x ^= quick_calc_cached(x % p) + cache[p] = pow(x, w, P) + return cache[p] + + return quick_calc_cached(p) +``` + +Về cơ bản, nó chỉ đơn giản là một bản viết lại của thuật toán trên, loại bỏ vòng lặp tính toán các giá trị cho toàn bộ DAG và thay thế việc tra cứu nút trước đó bằng một lệnh gọi đệ quy hoặc một tra cứu bộ nhớ đệm. Lưu ý rằng đối với `k=1`, bộ nhớ đệm là không cần thiết, mặc dù một tối ưu hóa sâu hơn thực sự tính toán trước vài nghìn giá trị đầu tiên của DAG và giữ đó làm bộ nhớ đệm tĩnh cho các phép tính; xem phụ lục để biết mã triển khai của việc này. + +## Bộ đệm kép của các DAG {#double-buffer} + +Trong một ứng dụng đầy đủ, một [_bộ đệm kép_](https://wikipedia.org/wiki/Multiple_buffering) gồm 2 DAG được tạo ra bởi công thức trên được sử dụng. Ý tưởng là các DAG được tạo ra mỗi `epochtime` khối theo các tham số ở trên. Thay vì ứng dụng sử dụng DAG mới nhất được tạo ra, nó sử dụng DAG trước đó. Lợi ích của việc này là nó cho phép các DAG được thay thế theo thời gian mà không cần phải kết hợp một bước mà các thợ đào phải đột ngột tính toán lại tất cả dữ liệu. Nếu không, có khả năng xử lý chuỗi sẽ bị chậm lại đột ngột và tạm thời ở các khoảng thời gian đều đặn và làm tăng đáng kể sự tập trung hóa. Do đó có rủi ro tấn công 51% trong vòng vài phút trước khi tất cả dữ liệu được tính toán lại. + +Thuật toán được sử dụng để tạo tập hợp các DAG được sử dụng để tính toán công việc cho một khối như sau: + +```python +def get_prevhash(n): + from pyethereum.blocks import GENESIS_PREVHASH + from pyethereum import chain_manager + if n <= 0: + return hash_to_int(GENESIS_PREVHASH) + else: + prevhash = chain_manager.index.get_block_by_number(n - 1) + return decode_int(prevhash) + +def get_seedset(params, block): + seedset = {} + seedset["back_number"] = block.number - (block.number % params["epochtime"]) + seedset["back_hash"] = get_prevhash(seedset["back_number"]) + seedset["front_number"] = max(seedset["back_number"] - params["epochtime"], 0) + seedset["front_hash"] = get_prevhash(seedset["front_number"]) + return seedset + +def get_dagsize(params, block): + return params["n"] + (block.number // params["epochtime"]) * params["n_inc"] + +def get_daggerset(params, block): + dagsz = get_dagsize(params, block) + seedset = get_seedset(params, block) + if seedset["front_hash"] <= 0: + # Không thể có bộ đệm sau, chỉ cần tạo bộ đệm trước + return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), + "block_number": 0}} + else: + return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), + "block_number": seedset["front_number"]}, + "back": {"dag": produce_dag(params, seedset["back_hash"], dagsz), + "block_number": seedset["back_number"]}} +``` + +## Hashimoto {#hashimoto} + +Ý tưởng đằng sau Hashimoto ban đầu là sử dụng chuỗi khối làm bộ dữ liệu, thực hiện một phép tính chọn N chỉ số từ chuỗi khối, thu thập các giao dịch tại các chỉ số đó, thực hiện phép XOR dữ liệu này và trả về giá trị băm của kết quả. Thuật toán ban đầu của Thaddeus Dryja, được dịch sang Python để đảm bảo tính nhất quán, như sau: + +```python +def orig_hashimoto(prev_hash, merkle_root, list_of_transactions, nonce): + hash_output_A = sha256(prev_hash + merkle_root + nonce) + txid_mix = 0 + for i in range(64): + shifted_A = hash_output_A >> i + transaction = shifted_A % len(list_of_transactions) + txid_mix ^= list_of_transactions[transaction] << i + return txid_mix ^ (nonce << 192) +``` + +Thật không may, mặc dù Hashimoto được coi là khó về RAM, nó lại dựa vào số học 256-bit, vốn có chi phí tính toán đáng kể. Tuy nhiên, Dagger-Hashimoto chỉ sử dụng 64 bit có trọng số thấp nhất khi lập chỉ mục cho bộ dữ liệu của mình để giải quyết vấn đề này. + +```python +def hashimoto(dag, dagsize, params, header, nonce): + m = dagsize / 2 + mix = sha3(encode_int(nonce) + header) + for _ in range(params["accesses"]): + mix ^= dag[m + (mix % 2**64) % m] + return dbl_sha3(mix) +``` + +Việc sử dụng double SHA3 cho phép một hình thức xác minh trước gần như tức thời, không có dữ liệu, chỉ xác minh rằng một giá trị trung gian chính xác đã được cung cấp. Lớp bằng chứng công việc bên ngoài này rất thân thiện với ASIC và khá yếu, nhưng tồn tại để làm cho việc tấn công DDoS trở nên khó khăn hơn vì một lượng nhỏ công việc đó phải được thực hiện để tạo ra một khối sẽ không bị từ chối ngay lập tức. Đây là phiên bản ứng dụng nhẹ: + +```python +def quick_hashimoto(seed, dagsize, params, header, nonce): + m = dagsize // 2 + mix = sha3(nonce + header) + for _ in range(params["accesses"]): + mix ^= quick_calc(params, seed, m + (mix % 2**64) % m) + return dbl_sha3(mix) +``` + +## Khai thác và xác minh {#mining-and-verifying} + +Bây giờ, chúng ta hãy kết hợp tất cả lại thành thuật toán khai thác: + +```python +def mine(daggerset, params, block): + from random import randint + nonce = randint(0, 2**64) + while 1: + result = hashimoto(daggerset, get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + if result * params["diff"] < 2**256: + break + nonce += 1 + if nonce >= 2**64: + nonce = 0 + return nonce +``` + +Đây là thuật toán xác minh: + +```python +def verify(daggerset, params, block, nonce): + result = hashimoto(daggerset, get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + return result * params["diff"] < 2**256 +``` + +Xác minh thân thiện với ứng dụng nhẹ: + +```python +def light_verify(params, header, nonce): + seedset = get_seedset(params, block) + result = quick_hashimoto(seedset["front_hash"], get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + return result * params["diff"] < 2**256 +``` + +Ngoài ra, lưu ý rằng Dagger-Hashimoto áp đặt các yêu cầu bổ sung đối với tiêu đề khối: + +- Để xác minh hai lớp hoạt động, tiêu đề khối phải có cả nonce và giá trị trung gian trước khi qua sha3 +- Ở đâu đó, tiêu đề khối phải lưu trữ sha3 của seedset hiện tại + +## Đọc thêm {#further-reading} + +_Biết về nguồn lực cộng đồng đã giúp đỡ bạn? Chỉnh sửa trang này và bổ sung!_ + +## Phụ lục {#appendix} + +Như đã lưu ý ở trên, RNG được sử dụng để tạo DAG dựa trên một số kết quả từ lý thuyết số. Đầu tiên, chúng tôi đảm bảo rằng Lehmer RNG, là cơ sở cho biến `picker`, có một chu kỳ dài. Thứ hai, chúng tôi chỉ ra rằng `pow(x,3,P)` sẽ không ánh xạ `x` tới `1` hoặc `P-1` với điều kiện `x ∈ [2,P-2]` ban đầu. Cuối cùng, chúng tôi chỉ ra rằng `pow(x,3,P)` có tỷ lệ xung đột thấp khi được coi là một hàm băm. + +### Trình tạo số ngẫu nhiên Lehmer {#lehmer-random-number} + +Mặc dù hàm `produce_dag` không cần tạo ra các số ngẫu nhiên không thiên vị, một mối đe dọa tiềm tàng là `seed**i % P` chỉ nhận một vài giá trị. Điều này có thể mang lại lợi thế cho những thợ đào nhận ra quy luật so với những người không nhận ra. + +Để tránh điều này, một kết quả từ lý thuyết số được sử dụng. Một [_Số nguyên tố an toàn_](https://en.wikipedia.org/wiki/Safe_prime) được định nghĩa là một số nguyên tố `P` sao cho `(P-1)/2` cũng là một số nguyên tố. Bậc của một thành viên `x` của [nhóm nhân](https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n) `ℤ/nℤ` được định nghĩa là `m` nhỏ nhất sao cho 
xᵐ mod P ≡ 1
+Với các định nghĩa này, chúng ta có: + +> Quan sát 1. Cho `x` là một thành viên của nhóm nhân `ℤ/Pℤ` đối với một số nguyên tố an toàn `P`. Nếu `x mod P ≠ 1 mod P` và `x mod P ≠ P-1 mod P`, thì bậc của `x` là `P-1` hoặc `(P-1)/2`. + +_Bằng chứng_. Vì `P` là một số nguyên tố an toàn, nên theo [Định lý Lagrange][lagrange], chúng ta có bậc của `x` là `1`, `2`, `(P-1)/2` hoặc `P-1`. + +Bậc của `x` không thể là `1`, vì theo Định lý nhỏ Fermat, chúng ta có: + +
xP-1 mod P ≡ 1
+ +Do đó, `x` phải là một phần tử đơn vị nhân của `ℤ/nℤ`, là duy nhất. Vì chúng ta đã giả định rằng `x ≠ 1`, điều này là không thể. + +Bậc của `x` không thể là `2` trừ khi `x = P-1`, vì điều này sẽ vi phạm tính nguyên tố của `P`. + +Từ mệnh đề trên, chúng ta có thể nhận ra rằng việc lặp `(picker * init) % P` sẽ có độ dài chu kỳ ít nhất là `(P-1)/2`. Điều này là do chúng tôi đã chọn `P` là một số nguyên tố an toàn xấp xỉ bằng một lũy thừa cao hơn của hai, và `init` nằm trong khoảng `[2,2**256+1]`. Với độ lớn của `P`, chúng ta không bao giờ nên mong đợi một chu kỳ từ phép lũy thừa theo mô-đun. + +Khi chúng ta gán ô đầu tiên trong DAG (biến có nhãn `init`), chúng ta tính toán `pow(sha3(seed) + 2, 3, P)`. Thoạt nhìn, điều này không đảm bảo rằng kết quả không phải là `1` cũng không phải là `P-1`. Tuy nhiên, vì `P-1` là một số nguyên tố an toàn, chúng tôi có thêm sự đảm bảo sau đây, là hệ quả của Quan sát 1: + +> Quan sát 2. Cho `x` là một thành viên của nhóm nhân `ℤ/Pℤ` đối với một số nguyên tố an toàn `P`, và cho `w` là một số tự nhiên. Nếu `x mod P ≠ 1 mod P` và `x mod P ≠ P-1 mod P`, cũng như `w mod P ≠ P-1 mod P` và `w mod P ≠ 0 mod P`, thì `xʷ mod P ≠ 1 mod P` và `xʷ mod P ≠ P-1 mod P` + +### Lũy thừa theo mô-đun như một hàm băm {#modular-exponentiation} + +Đối với các giá trị nhất định của `P` và `w`, hàm `pow(x, w, P)` có thể có nhiều xung đột. Ví dụ, `pow(x,9,19)` chỉ nhận các giá trị `{1,18}`. + +Với `P` là số nguyên tố, thì `w` thích hợp cho một hàm băm lũy thừa theo mô-đun có thể được chọn bằng cách sử dụng kết quả sau: + +> Quan sát 3. Cho `P` là một số nguyên tố; `w` và `P-1` là nguyên tố cùng nhau khi và chỉ khi với mọi `a` và `b` trong `ℤ/Pℤ`:
`aʷ mod P ≡ bʷ mod P` khi và chỉ khi `a mod P ≡ b mod P`
+ +Do đó, với `P` là số nguyên tố và `w` là nguyên tố cùng nhau với `P-1`, chúng ta có `|{pow(x, w, P) : x ∈ ℤ}| = P`, ngụ ý rằng hàm băm có tỷ lệ xung đột nhỏ nhất có thể. + +Trong trường hợp đặc biệt mà `P` là một số nguyên tố an toàn như chúng ta đã chọn, thì `P-1` chỉ có các ước số là 1, 2, `(P-1)/2` và `P-1`. Vì `P` > 7, chúng ta biết rằng 3 là nguyên tố cùng nhau với `P-1`, do đó `w=3` thỏa mãn mệnh đề trên. + +## Thuật toán đánh giá dựa trên bộ nhớ đệm hiệu quả hơn {#cache-based-evaluation} + +```python +def quick_calc(params, seed, p): + cache = produce_dag(params, seed, params["cache_size"]) + return quick_calc_cached(cache, params, p) + +def quick_calc_cached(cache, params, p): + P = params["P"] + if p < len(cache): + return cache[p] + else: + x = pow(cache[0], p + 1, P) + for _ in range(params["k"]): + x ^= quick_calc_cached(cache, params, x % p) + return pow(x, params["w"], P) + +def quick_hashimoto(seed, dagsize, params, header, nonce): + cache = produce_dag(params, seed, params["cache_size"]) + return quick_hashimoto_cached(cache, dagsize, params, header, nonce) + +def quick_hashimoto_cached(cache, dagsize, params, header, nonce): + m = dagsize // 2 + mask = 2**64 - 1 + mix = sha3(encode_int(nonce) + header) + for _ in range(params["accesses"]): + mix ^= quick_calc_cached(cache, params, m + (mix & mask) % m) + return dbl_sha3(mix) +``` diff --git a/public/content/translations/vi/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md b/public/content/translations/vi/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md new file mode 100644 index 00000000000..93cb1402392 --- /dev/null +++ b/public/content/translations/vi/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md @@ -0,0 +1,1022 @@ +--- +title: Ethash +description: "Cái nhìn chi tiết về thuật toán Ethash." +lang: vi +--- + + + + + + Ethash là thuật toán khai thác bằng chứng công việc của Ethereum. Bằng chứng công việc hiện đã được **tắt hoàn toàn** và Ethereum hiện được bảo mật bằng cách sử dụng [bằng chứng cổ phần](/developers/docs/consensus-mechanisms/pos/). Đọc thêm về [The Merge](/roadmap/merge/), [bằng chứng cổ phần](/developers/docs/consensus-mechanisms/pos/) và [đặt cược](/staking/). Trang này mang tính chất lịch sử! + + + + +Ethash là một phiên bản sửa đổi của thuật toán [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto). Bằng chứng công việc Ethash có [độ khó bộ nhớ](https://wikipedia.org/wiki/Memory-hard_function), điều này được cho là làm cho thuật toán có khả năng kháng vi mạch tích hợp chuyên dụng (ASIC). Các vi mạch tích hợp chuyên dụng (ASIC) Ethash cuối cùng đã được phát triển nhưng việc khai thác bằng GPU vẫn là một lựa chọn khả thi cho đến khi bằng chứng công việc bị tắt. Ethash vẫn được sử dụng để khai thác các đồng tiền mã hóa khác trên các mạng bằng chứng công việc không phải của Ethereum. + +## Ethash hoạt động như thế nào? {#how-does-ethash-work} + +Độ khó bộ nhớ đạt được bằng một thuật toán bằng chứng công việc yêu cầu chọn các tập hợp con của một tài nguyên cố định phụ thuộc vào nonce và tiêu đề khối. Tài nguyên này (kích thước vài gigabyte) được gọi là DAG. DAG được thay đổi sau mỗi 30.000 khối, một khoảng thời gian ~125 giờ được gọi là một tham số epoch (khoảng 5,2 ngày) và mất một khoảng thời gian để tạo. Vì DAG chỉ phụ thuộc vào chiều cao khối, nó có thể được tạo trước, nhưng nếu không, máy khách cần đợi cho đến khi kết thúc quá trình này để tạo ra một khối. Nếu các máy khách không tạo trước và lưu vào bộ đệm DAG trước thời hạn, mạng có thể gặp phải độ trễ khối lớn ở mỗi lần chuyển tiếp tham số epoch. Lưu ý rằng DAG không cần phải được tạo để xác minh bằng chứng công việc, về cơ bản cho phép xác minh bằng cả CPU thấp và bộ nhớ nhỏ. + +Lộ trình chung mà thuật toán thực hiện như sau: + +1. Tồn tại một **seed** có thể được tính toán cho mỗi khối bằng cách quét qua các tiêu đề khối cho đến thời điểm đó. +2. Từ seed, người ta có thể tính toán một **bộ đệm giả ngẫu nhiên 16 MB**. Các máy khách nhẹ lưu trữ bộ đệm. +3. Từ bộ đệm, chúng ta có thể tạo ra một **bộ dữ liệu 1 GB**, với thuộc tính là mỗi mục trong bộ dữ liệu chỉ phụ thuộc vào một số lượng nhỏ các mục từ bộ đệm. Các máy khách đầy đủ và thợ đào lưu trữ bộ dữ liệu. Bộ dữ liệu tăng tuyến tính theo thời gian. +4. Việc khai thác bao gồm việc lấy các lát ngẫu nhiên của bộ dữ liệu và băm chúng lại với nhau. Việc xác minh có thể được thực hiện với bộ nhớ thấp bằng cách sử dụng bộ đệm để tái tạo các phần cụ thể của bộ dữ liệu mà bạn cần, vì vậy bạn chỉ cần lưu trữ bộ đệm. + +Bộ dữ liệu lớn được cập nhật sau mỗi 30.000 khối, vì vậy phần lớn nỗ lực của một thợ đào sẽ là đọc bộ dữ liệu chứ không phải thay đổi nó. + +## Các định nghĩa {#definitions} + +Chúng tôi sử dụng các định nghĩa sau: + +``` +WORD_BYTES = 4 # byte trong một từ +DATASET_BYTES_INIT = 2**30 # byte trong bộ dữ liệu tại genesis +DATASET_BYTES_GROWTH = 2**23 # sự tăng trưởng của bộ dữ liệu trên mỗi tham số epoch +CACHE_BYTES_INIT = 2**24 # byte trong bộ đệm tại genesis +CACHE_BYTES_GROWTH = 2**17 # sự tăng trưởng của bộ đệm trên mỗi tham số epoch +CACHE_MULTIPLIER=1024 # Kích thước của DAG so với bộ đệm +EPOCH_LENGTH = 30000 # khối trên mỗi tham số epoch +MIX_BYTES = 128 # độ rộng của mix +HASH_BYTES = 64 # độ dài hàm băm tính bằng byte +DATASET_PARENTS = 256 # số lượng các mục cha của mỗi phần tử trong bộ dữ liệu +CACHE_ROUNDS = 3 # số vòng trong quá trình sản xuất bộ đệm +ACCESSES = 64 # số lần truy cập trong vòng lặp hashimoto +``` + +### Việc sử dụng 'SHA3' {#sha3} + +Sự phát triển của Ethereum trùng hợp với sự phát triển của tiêu chuẩn SHA3 và quy trình +tiêu chuẩn đã có một thay đổi muộn trong phần đệm của thuật toán băm cuối cùng, do đó các hàm băm +"sha3_256" và "sha3_512" của Ethereum không phải là các hàm băm sha3 tiêu chuẩn, mà là một biến thể thường được gọi +là "Keccak-256" và "Keccak-512" trong các ngữ cảnh khác. Xem thảo luận, ví dụ, [tại đây](https://eips.ethereum.org/EIPS/eip-1803), [tại đây](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use), hoặc [tại đây](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057). + +Vui lòng lưu ý điều đó khi các hàm băm "sha3" được đề cập trong phần mô tả thuật toán bên dưới. + +## Các tham số {#parameters} + +Các tham số cho bộ đệm và bộ dữ liệu của Ethash phụ thuộc vào số khối. Kích thước bộ đệm và kích thước bộ dữ liệu đều tăng tuyến tính; tuy nhiên, chúng tôi luôn lấy số nguyên tố cao nhất dưới ngưỡng tăng tuyến tính để giảm nguy cơ xảy ra các quy luật ngẫu nhiên dẫn đến hành vi tuần hoàn. + +```python +def get_cache_size(block_number): + sz = CACHE_BYTES_INIT + CACHE_BYTES_GROWTH * (block_number // EPOCH_LENGTH) + sz -= HASH_BYTES + while not isprime(sz / HASH_BYTES): + sz -= 2 * HASH_BYTES + return sz + +def get_full_size(block_number): + sz = DATASET_BYTES_INIT + DATASET_BYTES_GROWTH * (block_number // EPOCH_LENGTH) + sz -= MIX_BYTES + while not isprime(sz / MIX_BYTES): + sz -= 2 * MIX_BYTES + return sz +``` + +Các bảng giá trị kích thước bộ dữ liệu và kích thước bộ đệm được cung cấp trong phụ lục. + +## Tạo bộ đệm {#cache-generation} + +Bây giờ, chúng tôi chỉ định hàm để tạo một bộ đệm: + +```python +def mkcache(cache_size, seed): + n = cache_size // HASH_BYTES + + # Tạo tuần tự bộ dữ liệu ban đầu + o = [sha3_512(seed)] + for i in range(1, n): + o.append(sha3_512(o[-1])) + + # Sử dụng một phiên bản ít vòng lặp của randmemohash + for _ in range(CACHE_ROUNDS): + for i in range(n): + v = o[i][0] % n + o[i] = sha3_512(map(xor, o[(i-1+n) % n], o[v])) + + return o +``` + +Quá trình sản xuất bộ đệm bao gồm việc đầu tiên điền tuần tự 32 MB bộ nhớ, sau đó thực hiện hai lần duyệt thuật toán _RandMemoHash_ của Sergio Demian Lerner từ [_Strict Memory Hard Hashing Functions_ (2014)](http://www.hashcash.org/papers/memohash.pdf). Đầu ra là một tập hợp gồm 524.288 giá trị 64 byte. + +## Hàm tổng hợp dữ liệu {#date-aggregation-function} + +Chúng tôi sử dụng một thuật toán lấy cảm hứng từ [hàm băm FNV](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function) trong một số trường hợp như một sự thay thế không liên kết cho XOR. Lưu ý rằng chúng tôi nhân số nguyên tố với toàn bộ đầu vào 32 bit, trái ngược với đặc tả FNV-1 nhân số nguyên tố với lần lượt một byte (octet). + +```python +FNV_PRIME = 0x01000193 + +def fnv(v1, v2): + return ((v1 * FNV_PRIME) ^ v2) % 2**32 +``` + +Xin lưu ý, ngay cả sách vàng cũng chỉ định fnv là v1\*(FNV_PRIME ^ v2), tất cả các triển khai hiện tại đều nhất quán sử dụng định nghĩa trên. + +## Tính toán bộ dữ liệu đầy đủ {#full-dataset-calculation} + +Mỗi mục 64 byte trong bộ dữ liệu 1 GB đầy đủ được tính toán như sau: + +```python +def calc_dataset_item(cache, i): + n = len(cache) + r = HASH_BYTES // WORD_BYTES + # khởi tạo mix + mix = copy.copy(cache[i % n]) + mix[0] ^= i + mix = sha3_512(mix) + # thực hiện fnv với nhiều nút bộ đệm ngẫu nhiên dựa trên i + for j in range(DATASET_PARENTS): + cache_index = fnv(i ^ j, mix[j % r]) + mix = map(fnv, mix, cache[cache_index % n]) + return sha3_512(mix) +``` + +Về cơ bản, chúng tôi kết hợp dữ liệu từ 256 nút bộ đệm được chọn giả ngẫu nhiên và băm dữ liệu đó để tính toán nút bộ dữ liệu. Toàn bộ bộ dữ liệu sau đó được tạo bởi: + +```python +def calc_dataset(full_size, cache): + return [calc_dataset_item(cache, i) for i in range(full_size // HASH_BYTES)] +``` + +## Vòng lặp chính {#main-loop} + +Bây giờ, chúng tôi chỉ định vòng lặp chính giống như "hashimoto", nơi chúng tôi tổng hợp dữ liệu từ bộ dữ liệu đầy đủ để tạo ra giá trị cuối cùng cho một tiêu đề và nonce cụ thể. `header` đại diện cho _hàm băm_ SHA3-256 của biểu diễn RLP của một tiêu đề khối _bị cắt ngắn_, tức là của một tiêu đề không bao gồm các trường **mixHash** và **nonce**. `nonce` là tám byte của một số nguyên không dấu 64 bit theo thứ tự big-endian. Vì vậy, `nonce[::-1]` là biểu diễn little-endian tám byte của giá trị đó: + +```python +def hashimoto(header, nonce, full_size, dataset_lookup): + n = full_size / HASH_BYTES + w = MIX_BYTES // WORD_BYTES + mixhashes = MIX_BYTES / HASH_BYTES + # kết hợp header+nonce thành một seed 64 byte + s = sha3_512(header + nonce[::-1]) + # bắt đầu mix với s được nhân bản + mix = [] + for _ in range(MIX_BYTES / HASH_BYTES): + mix.extend(s) + # trộn trong các nút bộ dữ liệu ngẫu nhiên + for i in range(ACCESSES): + p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes + newdata = [] + for j in range(MIX_BYTES / HASH_BYTES): + newdata.extend(dataset_lookup(p + j)) + mix = map(fnv, mix, newdata) + # nén mix + cmix = [] + for i in range(0, len(mix), 4): + cmix.append(fnv(fnv(fnv(mix[i], mix[i+1]), mix[i+2]), mix[i+3])) + return { + "mix digest": serialize_hash(cmix), + "result": serialize_hash(sha3_256(s+cmix)) + } + +def hashimoto_light(full_size, cache, header, nonce): + return hashimoto(header, nonce, full_size, lambda x: calc_dataset_item(cache, x)) + +def hashimoto_full(full_size, dataset, header, nonce): + return hashimoto(header, nonce, full_size, lambda x: dataset[x]) +``` + +Về cơ bản, chúng tôi duy trì một "mix" rộng 128 byte và liên tục tìm nạp tuần tự 128 byte từ bộ dữ liệu đầy đủ và sử dụng hàm `fnv` để kết hợp nó với mix. 128 byte truy cập tuần tự được sử dụng để mỗi vòng của thuật toán luôn tìm nạp một trang đầy đủ từ RAM, giảm thiểu việc bỏ lỡ bộ đệm tra cứu biên dịch mà về mặt lý thuyết, các vi mạch tích hợp chuyên dụng (ASIC) có thể tránh được. + +Nếu đầu ra của thuật toán này thấp hơn mục tiêu mong muốn, thì nonce là hợp lệ. Lưu ý rằng việc áp dụng thêm `sha3_256` ở cuối đảm bảo rằng tồn tại một nonce trung gian có thể được cung cấp để chứng minh rằng ít nhất một lượng nhỏ công việc đã được thực hiện; việc xác minh PoW (Bằng chứng công việc) bên ngoài nhanh chóng này có thể được sử dụng cho các mục đích chống DDoS. Nó cũng dùng để cung cấp sự đảm bảo về mặt thống kê rằng kết quả là một số 256-bit không thiên vị. + +## Khai thác {#mining} + +Thuật toán khai thác được định nghĩa như sau: + +```python +def mine(full_size, dataset, header, difficulty): + # đệm số không vào mục tiêu để so sánh với hàm băm trên cùng một chữ số + target = zpad(encode_int(2**256 // difficulty), 64)[::-1] + from random import randint + nonce = randint(0, 2**64) + while hashimoto_full(full_size, dataset, header, nonce) > target: + nonce = (nonce + 1) % 2**64 + return nonce +``` + +## Định nghĩa hàm băm seed {#seed-hash} + +Để tính toán hàm băm seed sẽ được sử dụng để khai thác trên một khối nhất định, chúng tôi sử dụng thuật toán sau: + +```python + def get_seedhash(block): + s = '\x00' * 32 + for i in range(block.number // EPOCH_LENGTH): + s = serialize_hash(sha3_256(s)) + return s +``` + +Lưu ý rằng để khai thác và xác minh trơn tru, chúng tôi khuyên bạn nên tính toán trước các hàm băm seed và bộ dữ liệu trong tương lai trong một luồng riêng biệt. + +## Đọc thêm {#further-reading} + +_Biết về nguồn lực cộng đồng đã giúp đỡ bạn? Chỉnh sửa trang này và bổ sung!_ + +## Phụ lục {#appendix} + +Đoạn mã sau đây nên được đặt trước nếu bạn muốn chạy đặc tả python ở trên dưới dạng mã. + +```python +import sha3, copy + +# Giả định thứ tự bit little endian (giống như kiến trúc Intel) +def decode_int(s): + return int(s[::-1].encode('hex'), 16) if s else 0 + +def encode_int(s): + a = "%x" % s + return '' if s == 0 else ('0' * (len(a) % 2) + a).decode('hex')[::-1] + +def zpad(s, length): + return s + '\x00' * max(0, length - len(s)) + +def serialize_hash(h): + return ''.join([zpad(encode_int(x), 4) for x in h]) + +def deserialize_hash(h): + return [decode_int(h[i:i+WORD_BYTES]) for i in range(0, len(h), WORD_BYTES)] + +def hash_words(h, sz, x): + if isinstance(x, list): + x = serialize_hash(x) + y = h(x) + return deserialize_hash(y) + +def serialize_cache(ds): + return ''.join([serialize_hash(h) for h in ds]) + +serialize_dataset = serialize_cache + +# hàm băm sha3, đầu ra 64 byte +def sha3_512(x): + return hash_words(lambda v: sha3.sha3_512(v).digest(), 64, x) + +def sha3_256(x): + return hash_words(lambda v: sha3.sha3_256(v).digest(), 32, x) + +def xor(a, b): + return a ^ b + +def isprime(x): + for i in range(2, int(x**0.5)): + if x % i == 0: + return False + return True +``` + +### Kích thước dữ liệu {#data-sizes} + +Các bảng tra cứu sau đây cung cấp khoảng 2048 tham số epoch được lập bảng về kích thước dữ liệu và kích thước bộ đệm. + +```python +def get_datasize(block_number): + return data_sizes[block_number // EPOCH_LENGTH] + +def get_cachesize(block_number): + return cache_sizes[block_number // EPOCH_LENGTH] + +data_sizes = [ +1073739904, 1082130304, 1090514816, 1098906752, 1107293056, +1115684224, 1124070016, 1132461952, 1140849536, 1149232768, +1157627776, 1166013824, 1174404736, 1182786944, 1191180416, +1199568512, 1207958912, 1216345216, 1224732032, 1233124736, +1241513344, 1249902464, 1258290304, 1266673792, 1275067264, +1283453312, 1291844992, 1300234112, 1308619904, 1317010048, +1325397376, 1333787776, 1342176128, 1350561664, 1358954368, +1367339392, 1375731584, 1384118144, 1392507008, 1400897408, +1409284736, 1417673344, 1426062464, 1434451072, 1442839168, +1451229056, 1459615616, 1468006016, 1476394112, 1484782976, +1493171584, 1501559168, 1509948032, 1518337664, 1526726528, +1535114624, 1543503488, 1551892096, 1560278656, 1568669056, +1577056384, 1585446272, 1593831296, 1602219392, 1610610304, +1619000192, 1627386752, 1635773824, 1644164224, 1652555648, +1660943488, 1669332608, 1677721216, 1686109312, 1694497664, +1702886272, 1711274624, 1719661184, 1728047744, 1736434816, +1744829056, 1753218944, 1761606272, 1769995904, 1778382464, +1786772864, 1795157888, 1803550592, 1811937664, 1820327552, +1828711552, 1837102976, 1845488768, 1853879936, 1862269312, +1870656896, 1879048064, 1887431552, 1895825024, 1904212096, +1912601216, 1920988544, 1929379456, 1937765504, 1946156672, +1954543232, 1962932096, 1971321728, 1979707264, 1988093056, +1996487552, 2004874624, 2013262208, 2021653888, 2030039936, +2038430848, 2046819968, 2055208576, 2063596672, 2071981952, +2080373632, 2088762752, 2097149056, 2105539712, 2113928576, +2122315136, 2130700672, 2139092608, 2147483264, 2155872128, +2164257664, 2172642176, 2181035392, 2189426048, 2197814912, +2206203008, 2214587264, 2222979712, 2231367808, 2239758208, +2248145024, 2256527744, 2264922752, 2273312128, 2281701248, +2290086272, 2298476672, 2306867072, 2315251072, 2323639168, +2332032128, 2340420224, 2348808064, 2357196416, 2365580416, +2373966976, 2382363008, 2390748544, 2399139968, 2407530368, +2415918976, 2424307328, 2432695424, 2441084288, 2449472384, +2457861248, 2466247808, 2474637184, 2483026816, 2491414144, +2499803776, 2508191872, 2516582272, 2524970368, 2533359232, +2541743488, 2550134144, 2558525056, 2566913408, 2575301504, +2583686528, 2592073856, 2600467328, 2608856192, 2617240448, +2625631616, 2634022016, 2642407552, 2650796416, 2659188352, +2667574912, 2675965312, 2684352896, 2692738688, 2701130624, +2709518464, 2717907328, 2726293376, 2734685056, 2743073152, +2751462016, 2759851648, 2768232832, 2776625536, 2785017728, +2793401984, 2801794432, 2810182016, 2818571648, 2826959488, +2835349376, 2843734144, 2852121472, 2860514432, 2868900992, +2877286784, 2885676928, 2894069632, 2902451584, 2910843008, +2919234688, 2927622784, 2936011648, 2944400768, 2952789376, +2961177728, 2969565568, 2977951616, 2986338944, 2994731392, +3003120256, 3011508352, 3019895936, 3028287104, 3036675968, +3045063808, 3053452928, 3061837696, 3070228352, 3078615424, +3087003776, 3095394944, 3103782272, 3112173184, 3120562048, +3128944768, 3137339264, 3145725056, 3154109312, 3162505088, +3170893184, 3179280256, 3187669376, 3196056704, 3204445568, +3212836736, 3221224064, 3229612928, 3238002304, 3246391168, +3254778496, 3263165824, 3271556224, 3279944576, 3288332416, +3296719232, 3305110912, 3313500032, 3321887104, 3330273152, +3338658944, 3347053184, 3355440512, 3363827072, 3372220288, +3380608384, 3388997504, 3397384576, 3405774208, 3414163072, +3422551936, 3430937984, 3439328384, 3447714176, 3456104576, +3464493952, 3472883584, 3481268864, 3489655168, 3498048896, +3506434432, 3514826368, 3523213952, 3531603584, 3539987072, +3548380288, 3556763264, 3565157248, 3573545344, 3581934464, +3590324096, 3598712704, 3607098752, 3615488384, 3623877248, +3632265856, 3640646528, 3649043584, 3657430144, 3665821568, +3674207872, 3682597504, 3690984832, 3699367808, 3707764352, +3716152448, 3724541056, 3732925568, 3741318016, 3749706368, +3758091136, 3766481536, 3774872704, 3783260032, 3791650432, +3800036224, 3808427648, 3816815488, 3825204608, 3833592704, +3841981568, 3850370432, 3858755968, 3867147904, 3875536256, +3883920512, 3892313728, 3900702592, 3909087872, 3917478784, +3925868416, 3934256512, 3942645376, 3951032192, 3959422336, +3967809152, 3976200064, 3984588416, 3992974976, 4001363584, +4009751168, 4018141312, 4026530432, 4034911616, 4043308928, +4051695488, 4060084352, 4068472448, 4076862848, 4085249408, +4093640576, 4102028416, 4110413696, 4118805632, 4127194496, +4135583104, 4143971968, 4152360832, 4160746112, 4169135744, +4177525888, 4185912704, 4194303616, 4202691968, 4211076736, +4219463552, 4227855488, 4236246656, 4244633728, 4253022848, +4261412224, 4269799808, 4278184832, 4286578048, 4294962304, +4303349632, 4311743104, 4320130432, 4328521088, 4336909184, +4345295488, 4353687424, 4362073472, 4370458496, 4378852736, +4387238528, 4395630208, 4404019072, 4412407424, 4420790656, +4429182848, 4437571456, 4445962112, 4454344064, 4462738048, +4471119232, 4479516544, 4487904128, 4496289664, 4504682368, +4513068416, 4521459584, 4529846144, 4538232704, 4546619776, +4555010176, 4563402112, 4571790208, 4580174464, 4588567936, +4596957056, 4605344896, 4613734016, 4622119808, 4630511488, +4638898816, 4647287936, 4655675264, 4664065664, 4672451968, +4680842624, 4689231488, 4697620352, 4706007424, 4714397056, +4722786176, 4731173248, 4739562368, 4747951744, 4756340608, +4764727936, 4773114496, 4781504384, 4789894784, 4798283648, +4806667648, 4815059584, 4823449472, 4831835776, 4840226176, +4848612224, 4857003392, 4865391488, 4873780096, 4882169728, +4890557312, 4898946944, 4907333248, 4915722368, 4924110976, +4932499328, 4940889728, 4949276032, 4957666432, 4966054784, +4974438016, 4982831488, 4991221376, 4999607168, 5007998848, +5016386432, 5024763776, 5033164672, 5041544576, 5049941888, +5058329728, 5066717056, 5075107456, 5083494272, 5091883904, +5100273536, 5108662144, 5117048192, 5125436032, 5133827456, +5142215296, 5150605184, 5158993024, 5167382144, 5175769472, +5184157568, 5192543872, 5200936064, 5209324928, 5217711232, +5226102656, 5234490496, 5242877312, 5251263872, 5259654016, +5268040832, 5276434304, 5284819328, 5293209728, 5301598592, +5309986688, 5318374784, 5326764416, 5335151488, 5343542144, +5351929472, 5360319872, 5368706944, 5377096576, 5385484928, +5393871232, 5402263424, 5410650496, 5419040384, 5427426944, +5435816576, 5444205952, 5452594816, 5460981376, 5469367936, +5477760896, 5486148736, 5494536832, 5502925952, 5511315328, +5519703424, 5528089984, 5536481152, 5544869504, 5553256064, +5561645696, 5570032768, 5578423936, 5586811264, 5595193216, +5603585408, 5611972736, 5620366208, 5628750464, 5637143936, +5645528192, 5653921408, 5662310272, 5670694784, 5679082624, +5687474048, 5695864448, 5704251008, 5712641408, 5721030272, +5729416832, 5737806208, 5746194304, 5754583936, 5762969984, +5771358592, 5779748224, 5788137856, 5796527488, 5804911232, +5813300608, 5821692544, 5830082176, 5838468992, 5846855552, +5855247488, 5863636096, 5872024448, 5880411008, 5888799872, +5897186432, 5905576832, 5913966976, 5922352768, 5930744704, +5939132288, 5947522432, 5955911296, 5964299392, 5972688256, +5981074304, 5989465472, 5997851008, 6006241408, 6014627968, +6023015552, 6031408256, 6039796096, 6048185216, 6056574848, +6064963456, 6073351808, 6081736064, 6090128768, 6098517632, +6106906496, 6115289216, 6123680896, 6132070016, 6140459648, +6148849024, 6157237376, 6165624704, 6174009728, 6182403712, +6190792064, 6199176064, 6207569792, 6215952256, 6224345216, +6232732544, 6241124224, 6249510272, 6257899136, 6266287744, +6274676864, 6283065728, 6291454336, 6299843456, 6308232064, +6316620928, 6325006208, 6333395584, 6341784704, 6350174848, +6358562176, 6366951296, 6375337856, 6383729536, 6392119168, +6400504192, 6408895616, 6417283456, 6425673344, 6434059136, +6442444672, 6450837376, 6459223424, 6467613056, 6476004224, +6484393088, 6492781952, 6501170048, 6509555072, 6517947008, +6526336384, 6534725504, 6543112832, 6551500672, 6559888768, +6568278656, 6576662912, 6585055616, 6593443456, 6601834112, +6610219648, 6618610304, 6626999168, 6635385472, 6643777408, +6652164224, 6660552832, 6668941952, 6677330048, 6685719424, +6694107776, 6702493568, 6710882176, 6719274112, 6727662976, +6736052096, 6744437632, 6752825984, 6761213824, 6769604224, +6777993856, 6786383488, 6794770816, 6803158144, 6811549312, +6819937664, 6828326528, 6836706176, 6845101696, 6853491328, +6861880448, 6870269312, 6878655104, 6887046272, 6895433344, +6903822208, 6912212864, 6920596864, 6928988288, 6937377152, +6945764992, 6954149248, 6962544256, 6970928768, 6979317376, +6987709312, 6996093824, 7004487296, 7012875392, 7021258624, +7029652352, 7038038912, 7046427776, 7054818944, 7063207808, +7071595136, 7079980928, 7088372608, 7096759424, 7105149824, +7113536896, 7121928064, 7130315392, 7138699648, 7147092352, +7155479168, 7163865728, 7172249984, 7180648064, 7189036672, +7197424768, 7205810816, 7214196608, 7222589824, 7230975104, +7239367552, 7247755904, 7256145536, 7264533376, 7272921472, +7281308032, 7289694848, 7298088832, 7306471808, 7314864512, +7323253888, 7331643008, 7340029568, 7348419712, 7356808832, +7365196672, 7373585792, 7381973888, 7390362752, 7398750592, +7407138944, 7415528576, 7423915648, 7432302208, 7440690304, +7449080192, 7457472128, 7465860992, 7474249088, 7482635648, +7491023744, 7499412608, 7507803008, 7516192384, 7524579968, +7532967296, 7541358464, 7549745792, 7558134656, 7566524032, +7574912896, 7583300992, 7591690112, 7600075136, 7608466816, +7616854912, 7625244544, 7633629824, 7642020992, 7650410368, +7658794112, 7667187328, 7675574912, 7683961984, 7692349568, +7700739712, 7709130368, 7717519232, 7725905536, 7734295424, +7742683264, 7751069056, 7759457408, 7767849088, 7776238208, +7784626816, 7793014912, 7801405312, 7809792128, 7818179968, +7826571136, 7834957184, 7843347328, 7851732352, 7860124544, +7868512384, 7876902016, 7885287808, 7893679744, 7902067072, +7910455936, 7918844288, 7927230848, 7935622784, 7944009344, +7952400256, 7960786048, 7969176704, 7977565312, 7985953408, +7994339968, 8002730368, 8011119488, 8019508096, 8027896192, +8036285056, 8044674688, 8053062272, 8061448832, 8069838464, +8078227328, 8086616704, 8095006592, 8103393664, 8111783552, +8120171392, 8128560256, 8136949376, 8145336704, 8153726848, +8162114944, 8170503296, 8178891904, 8187280768, 8195669632, +8204058496, 8212444544, 8220834176, 8229222272, 8237612672, +8246000768, 8254389376, 8262775168, 8271167104, 8279553664, +8287944064, 8296333184, 8304715136, 8313108352, 8321497984, +8329885568, 8338274432, 8346663296, 8355052928, 8363441536, +8371828352, 8380217984, 8388606592, 8396996224, 8405384576, +8413772672, 8422161536, 8430549376, 8438939008, 8447326592, +8455715456, 8464104832, 8472492928, 8480882048, 8489270656, +8497659776, 8506045312, 8514434944, 8522823808, 8531208832, +8539602304, 8547990656, 8556378752, 8564768384, 8573154176, +8581542784, 8589933952, 8598322816, 8606705024, 8615099264, +8623487872, 8631876992, 8640264064, 8648653952, 8657040256, +8665430656, 8673820544, 8682209152, 8690592128, 8698977152, +8707374464, 8715763328, 8724151424, 8732540032, 8740928384, +8749315712, 8757704576, 8766089344, 8774480768, 8782871936, +8791260032, 8799645824, 8808034432, 8816426368, 8824812928, +8833199488, 8841591424, 8849976448, 8858366336, 8866757248, +8875147136, 8883532928, 8891923328, 8900306816, 8908700288, +8917088384, 8925478784, 8933867392, 8942250368, 8950644608, +8959032704, 8967420544, 8975809664, 8984197504, 8992584064, +9000976256, 9009362048, 9017752448, 9026141312, 9034530688, +9042917504, 9051307904, 9059694208, 9068084864, 9076471424, +9084861824, 9093250688, 9101638528, 9110027648, 9118416512, +9126803584, 9135188096, 9143581312, 9151969664, 9160356224, +9168747136, 9177134464, 9185525632, 9193910144, 9202302848, +9210690688, 9219079552, 9227465344, 9235854464, 9244244864, +9252633472, 9261021824, 9269411456, 9277799296, 9286188928, +9294574208, 9302965888, 9311351936, 9319740032, 9328131968, +9336516736, 9344907392, 9353296768, 9361685888, 9370074752, +9378463616, 9386849408, 9395239808, 9403629184, 9412016512, +9420405376, 9428795008, 9437181568, 9445570688, 9453960832, +9462346624, 9470738048, 9479121536, 9487515008, 9495903616, +9504289664, 9512678528, 9521067904, 9529456256, 9537843584, +9546233728, 9554621312, 9563011456, 9571398784, 9579788672, +9588178304, 9596567168, 9604954496, 9613343104, 9621732992, +9630121856, 9638508416, 9646898816, 9655283584, 9663675776, +9672061312, 9680449664, 9688840064, 9697230464, 9705617536, +9714003584, 9722393984, 9730772608, 9739172224, 9747561088, +9755945344, 9764338816, 9772726144, 9781116544, 9789503872, +9797892992, 9806282624, 9814670464, 9823056512, 9831439232, +9839833984, 9848224384, 9856613504, 9865000576, 9873391232, +9881772416, 9890162816, 9898556288, 9906940544, 9915333248, +9923721088, 9932108672, 9940496512, 9948888448, 9957276544, +9965666176, 9974048384, 9982441088, 9990830464, 9999219584, +10007602816, 10015996544, 10024385152, 10032774016, 10041163648, +10049548928, 10057940096, 10066329472, 10074717824, 10083105152, +10091495296, 10099878784, 10108272256, 10116660608, 10125049216, +10133437312, 10141825664, 10150213504, 10158601088, 10166991232, +10175378816, 10183766144, 10192157312, 10200545408, 10208935552, +10217322112, 10225712768, 10234099328, 10242489472, 10250876032, +10259264896, 10267656064, 10276042624, 10284429184, 10292820352, +10301209472, 10309598848, 10317987712, 10326375296, 10334763392, +10343153536, 10351541632, 10359930752, 10368318592, 10376707456, +10385096576, 10393484672, 10401867136, 10410262144, 10418647424, +10427039104, 10435425664, 10443810176, 10452203648, 10460589952, +10468982144, 10477369472, 10485759104, 10494147712, 10502533504, +10510923392, 10519313536, 10527702656, 10536091264, 10544478592, +10552867712, 10561255808, 10569642368, 10578032768, 10586423168, +10594805632, 10603200128, 10611588992, 10619976064, 10628361344, +10636754048, 10645143424, 10653531776, 10661920384, 10670307968, +10678696832, 10687086464, 10695475072, 10703863168, 10712246144, +10720639616, 10729026688, 10737414784, 10745806208, 10754190976, +10762581376, 10770971264, 10779356288, 10787747456, 10796135552, +10804525184, 10812915584, 10821301888, 10829692288, 10838078336, +10846469248, 10854858368, 10863247232, 10871631488, 10880023424, +10888412032, 10896799616, 10905188992, 10913574016, 10921964672, +10930352768, 10938742912, 10947132544, 10955518592, 10963909504, +10972298368, 10980687488, 10989074816, 10997462912, 11005851776, +11014241152, 11022627712, 11031017344, 11039403904, 11047793024, +11056184704, 11064570752, 11072960896, 11081343872, 11089737856, +11098128256, 11106514816, 11114904448, 11123293568, 11131680128, +11140065152, 11148458368, 11156845696, 11165236864, 11173624192, +11182013824, 11190402688, 11198790784, 11207179136, 11215568768, +11223957376, 11232345728, 11240734592, 11249122688, 11257511296, +11265899648, 11274285952, 11282675584, 11291065472, 11299452544, +11307842432, 11316231296, 11324616832, 11333009024, 11341395584, +11349782656, 11358172288, 11366560384, 11374950016, 11383339648, +11391721856, 11400117376, 11408504192, 11416893568, 11425283456, +11433671552, 11442061184, 11450444672, 11458837888, 11467226752, +11475611776, 11484003968, 11492392064, 11500780672, 11509169024, +11517550976, 11525944448, 11534335616, 11542724224, 11551111808, +11559500672, 11567890304, 11576277376, 11584667008, 11593056128, +11601443456, 11609830016, 11618221952, 11626607488, 11634995072, +11643387776, 11651775104, 11660161664, 11668552576, 11676940928, +11685330304, 11693718656, 11702106496, 11710496128, 11718882688, +11727273088, 11735660416, 11744050048, 11752437376, 11760824704, +11769216128, 11777604736, 11785991296, 11794381952, 11802770048, +11811157888, 11819548544, 11827932544, 11836324736, 11844713344, +11853100928, 11861486464, 11869879936, 11878268032, 11886656896, +11895044992, 11903433088, 11911822976, 11920210816, 11928600448, +11936987264, 11945375872, 11953761152, 11962151296, 11970543488, +11978928512, 11987320448, 11995708288, 12004095104, 12012486272, +12020875136, 12029255552, 12037652096, 12046039168, 12054429568, +12062813824, 12071206528, 12079594624, 12087983744, 12096371072, +12104759936, 12113147264, 12121534592, 12129924992, 12138314624, +12146703232, 12155091584, 12163481216, 12171864704, 12180255872, +12188643968, 12197034112, 12205424512, 12213811328, 12222199424, +12230590336, 12238977664, 12247365248, 12255755392, 12264143488, +12272531584, 12280920448, 12289309568, 12297694592, 12306086528, +12314475392, 12322865024, 12331253632, 12339640448, 12348029312, +12356418944, 12364805248, 12373196672, 12381580928, 12389969024, +12398357632, 12406750592, 12415138432, 12423527552, 12431916416, +12440304512, 12448692352, 12457081216, 12465467776, 12473859968, +12482245504, 12490636672, 12499025536, 12507411584, 12515801728, +12524190592, 12532577152, 12540966272, 12549354368, 12557743232, +12566129536, 12574523264, 12582911872, 12591299456, 12599688064, +12608074624, 12616463488, 12624845696, 12633239936, 12641631616, +12650019968, 12658407296, 12666795136, 12675183232, 12683574656, +12691960192, 12700350592, 12708740224, 12717128576, 12725515904, +12733906816, 12742295168, 12750680192, 12759071872, 12767460736, +12775848832, 12784236928, 12792626816, 12801014656, 12809404288, +12817789312, 12826181504, 12834568832, 12842954624, 12851345792, +12859732352, 12868122496, 12876512128, 12884901248, 12893289088, +12901672832, 12910067584, 12918455168, 12926842496, 12935232896, +12943620736, 12952009856, 12960396928, 12968786816, 12977176192, +12985563776, 12993951104, 13002341504, 13010730368, 13019115392, +13027506304, 13035895168, 13044272512, 13052673152, 13061062528, +13069446272, 13077838976, 13086227072, 13094613632, 13103000192, +13111393664, 13119782528, 13128157568, 13136559232, 13144945024, +13153329536, 13161724288, 13170111872, 13178502784, 13186884736, +13195279744, 13203667072, 13212057472, 13220445824, 13228832128, +13237221248, 13245610624, 13254000512, 13262388352, 13270777472, +13279166336, 13287553408, 13295943296, 13304331904, 13312719488, +13321108096, 13329494656, 13337885824, 13346274944, 13354663808, +13363051136, 13371439232, 13379825024, 13388210816, 13396605056, +13404995456, 13413380224, 13421771392, 13430159744, 13438546048, +13446937216, 13455326848, 13463708288, 13472103808, 13480492672, +13488875648, 13497269888, 13505657728, 13514045312, 13522435712, +13530824576, 13539210112, 13547599232, 13555989376, 13564379008, +13572766336, 13581154432, 13589544832, 13597932928, 13606320512, +13614710656, 13623097472, 13631477632, 13639874944, 13648264064, +13656652928, 13665041792, 13673430656, 13681818496, 13690207616, +13698595712, 13706982272, 13715373184, 13723762048, 13732150144, +13740536704, 13748926592, 13757316224, 13765700992, 13774090112, +13782477952, 13790869376, 13799259008, 13807647872, 13816036736, +13824425344, 13832814208, 13841202304, 13849591424, 13857978752, +13866368896, 13874754688, 13883145344, 13891533184, 13899919232, +13908311168, 13916692096, 13925085056, 13933473152, 13941866368, +13950253696, 13958643584, 13967032192, 13975417216, 13983807616, +13992197504, 14000582272, 14008973696, 14017363072, 14025752192, +14034137984, 14042528384, 14050918016, 14059301504, 14067691648, +14076083584, 14084470144, 14092852352, 14101249664, 14109635968, +14118024832, 14126407552, 14134804352, 14143188608, 14151577984, +14159968384, 14168357248, 14176741504, 14185127296, 14193521024, +14201911424, 14210301824, 14218685056, 14227067264, 14235467392, +14243855488, 14252243072, 14260630144, 14269021568, 14277409408, +14285799296, 14294187904, 14302571392, 14310961792, 14319353728, +14327738752, 14336130944, 14344518784, 14352906368, 14361296512, +14369685376, 14378071424, 14386462592, 14394848128, 14403230848, +14411627392, 14420013952, 14428402304, 14436793472, 14445181568, +14453569664, 14461959808, 14470347904, 14478737024, 14487122816, +14495511424, 14503901824, 14512291712, 14520677504, 14529064832, +14537456768, 14545845632, 14554234496, 14562618496, 14571011456, +14579398784, 14587789184, 14596172672, 14604564608, 14612953984, +14621341312, 14629724288, 14638120832, 14646503296, 14654897536, +14663284864, 14671675264, 14680061056, 14688447616, 14696835968, +14705228416, 14713616768, 14722003328, 14730392192, 14738784128, +14747172736, 14755561088, 14763947648, 14772336512, 14780725376, +14789110144, 14797499776, 14805892736, 14814276992, 14822670208, +14831056256, 14839444352, 14847836032, 14856222848, 14864612992, +14872997504, 14881388672, 14889775744, 14898165376, 14906553472, +14914944896, 14923329664, 14931721856, 14940109696, 14948497024, +14956887424, 14965276544, 14973663616, 14982053248, 14990439808, +14998830976, 15007216768, 15015605888, 15023995264, 15032385152, +15040768384, 15049154944, 15057549184, 15065939072, 15074328448, +15082715008, 15091104128, 15099493504, 15107879296, 15116269184, +15124659584, 15133042304, 15141431936, 15149824384, 15158214272, +15166602368, 15174991232, 15183378304, 15191760512, 15200154496, +15208542592, 15216931712, 15225323392, 15233708416, 15242098048, +15250489216, 15258875264, 15267265408, 15275654528, 15284043136, +15292431488, 15300819584, 15309208192, 15317596544, 15325986176, +15334374784, 15342763648, 15351151744, 15359540608, 15367929728, +15376318336, 15384706432, 15393092992, 15401481856, 15409869952, +15418258816, 15426649984, 15435037568, 15443425664, 15451815296, +15460203392, 15468589184, 15476979328, 15485369216, 15493755776, +15502146944, 15510534272, 15518924416, 15527311232, 15535699072, +15544089472, 15552478336, 15560866688, 15569254528, 15577642624, +15586031488, 15594419072, 15602809472, 15611199104, 15619586432, +15627975296, 15636364928, 15644753792, 15653141888, 15661529216, +15669918848, 15678305152, 15686696576, 15695083136, 15703474048, +15711861632, 15720251264, 15728636288, 15737027456, 15745417088, +15753804928, 15762194048, 15770582656, 15778971008, 15787358336, +15795747712, 15804132224, 15812523392, 15820909696, 15829300096, +15837691264, 15846071936, 15854466944, 15862855808, 15871244672, +15879634816, 15888020608, 15896409728, 15904799104, 15913185152, +15921577088, 15929966464, 15938354816, 15946743424, 15955129472, +15963519872, 15971907968, 15980296064, 15988684928, 15997073024, +16005460864, 16013851264, 16022241152, 16030629248, 16039012736, +16047406976, 16055794816, 16064181376, 16072571264, 16080957824, +16089346688, 16097737856, 16106125184, 16114514816, 16122904192, +16131292544, 16139678848, 16148066944, 16156453504, 16164839552, +16173236096, 16181623424, 16190012032, 16198401152, 16206790528, +16215177344, 16223567744, 16231956352, 16240344704, 16248731008, +16257117824, 16265504384, 16273898624, 16282281856, 16290668672, +16299064192, 16307449216, 16315842176, 16324230016, 16332613504, +16341006464, 16349394304, 16357783168, 16366172288, 16374561664, +16382951296, 16391337856, 16399726208, 16408116352, 16416505472, +16424892032, 16433282176, 16441668224, 16450058624, 16458448768, +16466836864, 16475224448, 16483613056, 16492001408, 16500391808, +16508779648, 16517166976, 16525555328, 16533944192, 16542330752, +16550719616, 16559110528, 16567497088, 16575888512, 16584274816, +16592665472, 16601051008, 16609442944, 16617832064, 16626218624, +16634607488, 16642996096, 16651385728, 16659773824, 16668163712, +16676552576, 16684938112, 16693328768, 16701718144, 16710095488, +16718492288, 16726883968, 16735272832, 16743661184, 16752049792, +16760436608, 16768827008, 16777214336, 16785599104, 16793992832, +16802381696, 16810768768, 16819151744, 16827542656, 16835934848, +16844323712, 16852711552, 16861101952, 16869489536, 16877876864, +16886265728, 16894653056, 16903044736, 16911431296, 16919821696, +16928207488, 16936592768, 16944987776, 16953375616, 16961763968, +16970152832, 16978540928, 16986929536, 16995319168, 17003704448, +17012096896, 17020481152, 17028870784, 17037262208, 17045649536, +17054039936, 17062426496, 17070814336, 17079205504, 17087592064, +17095978112, 17104369024, 17112759424, 17121147776, 17129536384, +17137926016, 17146314368, 17154700928, 17163089792, 17171480192, +17179864192, 17188256896, 17196644992, 17205033856, 17213423488, +17221811072, 17230198912, 17238588032, 17246976896, 17255360384, +17263754624, 17272143232, 17280530048, 17288918912, 17297309312, +17305696384, 17314085504, 17322475136, 17330863744, 17339252096, +17347640192, 17356026496, 17364413824, 17372796544, 17381190016, +17389583488, 17397972608, 17406360704, 17414748544, 17423135872, +17431527296, 17439915904, 17448303232, 17456691584, 17465081728, +17473468288, 17481857408, 17490247552, 17498635904, 17507022464, +17515409024, 17523801728, 17532189824, 17540577664, 17548966016, +17557353344, 17565741184, 17574131584, 17582519168, 17590907008, +17599296128, 17607687808, 17616076672, 17624455808, 17632852352, +17641238656, 17649630848, 17658018944, 17666403968, 17674794112, +17683178368, 17691573376, 17699962496, 17708350592, 17716739968, +17725126528, 17733517184, 17741898112, 17750293888, 17758673024, +17767070336, 17775458432, 17783848832, 17792236928, 17800625536, +17809012352, 17817402752, 17825785984, 17834178944, 17842563968, +17850955648, 17859344512, 17867732864, 17876119424, 17884511872, +17892900224, 17901287296, 17909677696, 17918058112, 17926451072, +17934843776, 17943230848, 17951609216, 17960008576, 17968397696, +17976784256, 17985175424, 17993564032, 18001952128, 18010339712, +18018728576, 18027116672, 18035503232, 18043894144, 18052283264, +18060672128, 18069056384, 18077449856, 18085837184, 18094225792, +18102613376, 18111004544, 18119388544, 18127781248, 18136170368, +18144558976, 18152947328, 18161336192, 18169724288, 18178108544, +18186498944, 18194886784, 18203275648, 18211666048, 18220048768, +18228444544, 18236833408, 18245220736] + +cache_sizes = [ +16776896, 16907456, 17039296, 17170112, 17301056, 17432512, 17563072, +17693888, 17824192, 17955904, 18087488, 18218176, 18349504, 18481088, +18611392, 18742336, 18874304, 19004224, 19135936, 19267264, 19398208, +19529408, 19660096, 19791424, 19922752, 20053952, 20184896, 20315968, +20446912, 20576576, 20709184, 20840384, 20971072, 21102272, 21233216, +21364544, 21494848, 21626816, 21757376, 21887552, 22019392, 22151104, +22281536, 22412224, 22543936, 22675264, 22806464, 22935872, 23068096, +23198272, 23330752, 23459008, 23592512, 23723968, 23854912, 23986112, +24116672, 24247616, 24378688, 24509504, 24640832, 24772544, 24903488, +25034432, 25165376, 25296704, 25427392, 25558592, 25690048, 25820096, +25951936, 26081728, 26214208, 26345024, 26476096, 26606656, 26737472, +26869184, 26998208, 27131584, 27262528, 27393728, 27523904, 27655744, +27786688, 27917888, 28049344, 28179904, 28311488, 28441792, 28573504, +28700864, 28835648, 28966208, 29096768, 29228608, 29359808, 29490752, +29621824, 29752256, 29882816, 30014912, 30144448, 30273728, 30406976, +30538432, 30670784, 30799936, 30932672, 31063744, 31195072, 31325248, +31456192, 31588288, 31719232, 31850432, 31981504, 32110784, 32243392, +32372672, 32505664, 32636608, 32767808, 32897344, 33029824, 33160768, +33289664, 33423296, 33554368, 33683648, 33816512, 33947456, 34076992, +34208704, 34340032, 34471744, 34600256, 34734016, 34864576, 34993984, +35127104, 35258176, 35386688, 35518528, 35650624, 35782336, 35910976, +36044608, 36175808, 36305728, 36436672, 36568384, 36699968, 36830656, +36961984, 37093312, 37223488, 37355072, 37486528, 37617472, 37747904, +37879232, 38009792, 38141888, 38272448, 38403392, 38535104, 38660672, +38795584, 38925632, 39059264, 39190336, 39320768, 39452096, 39581632, +39713984, 39844928, 39974848, 40107968, 40238144, 40367168, 40500032, +40631744, 40762816, 40894144, 41023552, 41155904, 41286208, 41418304, +41547712, 41680448, 41811904, 41942848, 42073792, 42204992, 42334912, +42467008, 42597824, 42729152, 42860096, 42991552, 43122368, 43253696, +43382848, 43515712, 43646912, 43777088, 43907648, 44039104, 44170432, +44302144, 44433344, 44564288, 44694976, 44825152, 44956864, 45088448, +45219008, 45350464, 45481024, 45612608, 45744064, 45874496, 46006208, +46136768, 46267712, 46399424, 46529344, 46660672, 46791488, 46923328, +47053504, 47185856, 47316928, 47447872, 47579072, 47710144, 47839936, +47971648, 48103232, 48234176, 48365248, 48496192, 48627136, 48757312, +48889664, 49020736, 49149248, 49283008, 49413824, 49545152, 49675712, +49807168, 49938368, 50069056, 50200256, 50331584, 50462656, 50593472, +50724032, 50853952, 50986048, 51117632, 51248576, 51379904, 51510848, +51641792, 51773248, 51903296, 52035136, 52164032, 52297664, 52427968, +52557376, 52690112, 52821952, 52952896, 53081536, 53213504, 53344576, +53475776, 53608384, 53738816, 53870528, 54000832, 54131776, 54263744, +54394688, 54525248, 54655936, 54787904, 54918592, 55049152, 55181248, +55312064, 55442752, 55574336, 55705024, 55836224, 55967168, 56097856, +56228672, 56358592, 56490176, 56621888, 56753728, 56884928, 57015488, +57146816, 57278272, 57409216, 57540416, 57671104, 57802432, 57933632, +58064576, 58195264, 58326976, 58457408, 58588864, 58720192, 58849984, +58981696, 59113024, 59243456, 59375552, 59506624, 59637568, 59768512, +59897792, 60030016, 60161984, 60293056, 60423872, 60554432, 60683968, +60817216, 60948032, 61079488, 61209664, 61341376, 61471936, 61602752, +61733696, 61865792, 61996736, 62127808, 62259136, 62389568, 62520512, +62651584, 62781632, 62910784, 63045056, 63176128, 63307072, 63438656, +63569216, 63700928, 63831616, 63960896, 64093888, 64225088, 64355392, +64486976, 64617664, 64748608, 64879424, 65009216, 65142464, 65273792, +65402816, 65535424, 65666752, 65797696, 65927744, 66060224, 66191296, +66321344, 66453056, 66584384, 66715328, 66846656, 66977728, 67108672, +67239104, 67370432, 67501888, 67631296, 67763776, 67895104, 68026304, +68157248, 68287936, 68419264, 68548288, 68681408, 68811968, 68942912, +69074624, 69205568, 69337024, 69467584, 69599168, 69729472, 69861184, +69989824, 70122944, 70253888, 70385344, 70515904, 70647232, 70778816, +70907968, 71040832, 71171648, 71303104, 71432512, 71564992, 71695168, +71826368, 71958464, 72089536, 72219712, 72350144, 72482624, 72613568, +72744512, 72875584, 73006144, 73138112, 73268672, 73400128, 73530944, +73662272, 73793344, 73924544, 74055104, 74185792, 74316992, 74448832, +74579392, 74710976, 74841664, 74972864, 75102784, 75233344, 75364544, +75497024, 75627584, 75759296, 75890624, 76021696, 76152256, 76283072, +76414144, 76545856, 76676672, 76806976, 76937792, 77070016, 77200832, +77331392, 77462464, 77593664, 77725376, 77856448, 77987776, 78118336, +78249664, 78380992, 78511424, 78642496, 78773056, 78905152, 79033664, +79166656, 79297472, 79429568, 79560512, 79690816, 79822784, 79953472, +80084672, 80214208, 80346944, 80477632, 80608576, 80740288, 80870848, +81002048, 81133504, 81264448, 81395648, 81525952, 81657536, 81786304, +81919808, 82050112, 82181312, 82311616, 82443968, 82573376, 82705984, +82835776, 82967744, 83096768, 83230528, 83359552, 83491264, 83622464, +83753536, 83886016, 84015296, 84147776, 84277184, 84409792, 84540608, +84672064, 84803008, 84934336, 85065152, 85193792, 85326784, 85458496, +85589312, 85721024, 85851968, 85982656, 86112448, 86244416, 86370112, +86506688, 86637632, 86769344, 86900672, 87031744, 87162304, 87293632, +87424576, 87555392, 87687104, 87816896, 87947968, 88079168, 88211264, +88341824, 88473152, 88603712, 88735424, 88862912, 88996672, 89128384, +89259712, 89390272, 89521984, 89652544, 89783872, 89914816, 90045376, +90177088, 90307904, 90438848, 90569152, 90700096, 90832832, 90963776, +91093696, 91223744, 91356992, 91486784, 91618496, 91749824, 91880384, +92012224, 92143552, 92273344, 92405696, 92536768, 92666432, 92798912, +92926016, 93060544, 93192128, 93322816, 93453632, 93583936, 93715136, +93845056, 93977792, 94109504, 94240448, 94371776, 94501184, 94632896, +94764224, 94895552, 95023424, 95158208, 95287744, 95420224, 95550016, +95681216, 95811904, 95943872, 96075328, 96203584, 96337856, 96468544, +96599744, 96731072, 96860992, 96992576, 97124288, 97254848, 97385536, +97517248, 97647808, 97779392, 97910464, 98041408, 98172608, 98303168, +98434496, 98565568, 98696768, 98827328, 98958784, 99089728, 99220928, +99352384, 99482816, 99614272, 99745472, 99876416, 100007104, +100138048, 100267072, 100401088, 100529984, 100662592, 100791872, +100925248, 101056064, 101187392, 101317952, 101449408, 101580608, +101711296, 101841728, 101973824, 102104896, 102235712, 102366016, +102498112, 102628672, 102760384, 102890432, 103021888, 103153472, +103284032, 103415744, 103545152, 103677248, 103808576, 103939648, +104070976, 104201792, 104332736, 104462528, 104594752, 104725952, +104854592, 104988608, 105118912, 105247808, 105381184, 105511232, +105643072, 105774784, 105903296, 106037056, 106167872, 106298944, +106429504, 106561472, 106691392, 106822592, 106954304, 107085376, +107216576, 107346368, 107478464, 107609792, 107739712, 107872192, +108003136, 108131392, 108265408, 108396224, 108527168, 108657344, +108789568, 108920384, 109049792, 109182272, 109312576, 109444928, +109572928, 109706944, 109837888, 109969088, 110099648, 110230976, +110362432, 110492992, 110624704, 110755264, 110886208, 111017408, +111148864, 111279296, 111410752, 111541952, 111673024, 111803456, +111933632, 112066496, 112196416, 112328512, 112457792, 112590784, +112715968, 112852672, 112983616, 113114944, 113244224, 113376448, +113505472, 113639104, 113770304, 113901376, 114031552, 114163264, +114294592, 114425536, 114556864, 114687424, 114818624, 114948544, +115080512, 115212224, 115343296, 115473472, 115605184, 115736128, +115867072, 115997248, 116128576, 116260288, 116391488, 116522944, +116652992, 116784704, 116915648, 117046208, 117178304, 117308608, +117440192, 117569728, 117701824, 117833024, 117964096, 118094656, +118225984, 118357312, 118489024, 118617536, 118749632, 118882112, +119012416, 119144384, 119275328, 119406016, 119537344, 119668672, +119798464, 119928896, 120061376, 120192832, 120321728, 120454336, +120584512, 120716608, 120848192, 120979136, 121109056, 121241408, +121372352, 121502912, 121634752, 121764416, 121895744, 122027072, +122157632, 122289088, 122421184, 122550592, 122682944, 122813888, +122945344, 123075776, 123207488, 123338048, 123468736, 123600704, +123731264, 123861952, 123993664, 124124608, 124256192, 124386368, +124518208, 124649024, 124778048, 124911296, 125041088, 125173696, +125303744, 125432896, 125566912, 125696576, 125829056, 125958592, +126090304, 126221248, 126352832, 126483776, 126615232, 126746432, +126876608, 127008704, 127139392, 127270336, 127401152, 127532224, +127663552, 127794752, 127925696, 128055232, 128188096, 128319424, +128449856, 128581312, 128712256, 128843584, 128973632, 129103808, +129236288, 129365696, 129498944, 129629888, 129760832, 129892288, +130023104, 130154048, 130283968, 130416448, 130547008, 130678336, +130807616, 130939456, 131071552, 131202112, 131331776, 131464384, +131594048, 131727296, 131858368, 131987392, 132120256, 132250816, +132382528, 132513728, 132644672, 132774976, 132905792, 133038016, +133168832, 133299392, 133429312, 133562048, 133692992, 133823296, +133954624, 134086336, 134217152, 134348608, 134479808, 134607296, +134741056, 134872384, 135002944, 135134144, 135265472, 135396544, +135527872, 135659072, 135787712, 135921472, 136052416, 136182848, +136313792, 136444864, 136576448, 136707904, 136837952, 136970048, +137099584, 137232064, 137363392, 137494208, 137625536, 137755712, +137887424, 138018368, 138149824, 138280256, 138411584, 138539584, +138672832, 138804928, 138936128, 139066688, 139196864, 139328704, +139460032, 139590208, 139721024, 139852864, 139984576, 140115776, +140245696, 140376512, 140508352, 140640064, 140769856, 140902336, +141032768, 141162688, 141294016, 141426496, 141556544, 141687488, +141819584, 141949888, 142080448, 142212544, 142342336, 142474432, +142606144, 142736192, 142868288, 142997824, 143129408, 143258944, +143392448, 143523136, 143653696, 143785024, 143916992, 144045632, +144177856, 144309184, 144440768, 144570688, 144701888, 144832448, +144965056, 145096384, 145227584, 145358656, 145489856, 145620928, +145751488, 145883072, 146011456, 146144704, 146275264, 146407232, +146538176, 146668736, 146800448, 146931392, 147062336, 147193664, +147324224, 147455936, 147586624, 147717056, 147848768, 147979456, +148110784, 148242368, 148373312, 148503232, 148635584, 148766144, +148897088, 149028416, 149159488, 149290688, 149420224, 149551552, +149683136, 149814976, 149943616, 150076352, 150208064, 150338624, +150470464, 150600256, 150732224, 150862784, 150993088, 151125952, +151254976, 151388096, 151519168, 151649728, 151778752, 151911104, +152042944, 152174144, 152304704, 152435648, 152567488, 152698816, +152828992, 152960576, 153091648, 153222976, 153353792, 153484096, +153616192, 153747008, 153878336, 154008256, 154139968, 154270912, +154402624, 154533824, 154663616, 154795712, 154926272, 155057984, +155188928, 155319872, 155450816, 155580608, 155712064, 155843392, +155971136, 156106688, 156237376, 156367424, 156499264, 156630976, +156761536, 156892352, 157024064, 157155008, 157284416, 157415872, +157545536, 157677248, 157810496, 157938112, 158071744, 158203328, +158334656, 158464832, 158596288, 158727616, 158858048, 158988992, +159121216, 159252416, 159381568, 159513152, 159645632, 159776192, +159906496, 160038464, 160169536, 160300352, 160430656, 160563008, +160693952, 160822208, 160956352, 161086784, 161217344, 161349184, +161480512, 161611456, 161742272, 161873216, 162002752, 162135872, +162266432, 162397888, 162529216, 162660032, 162790976, 162922048, +163052096, 163184576, 163314752, 163446592, 163577408, 163707968, +163839296, 163969984, 164100928, 164233024, 164364224, 164494912, +164625856, 164756672, 164887616, 165019072, 165150016, 165280064, +165412672, 165543104, 165674944, 165805888, 165936832, 166067648, +166198336, 166330048, 166461248, 166591552, 166722496, 166854208, +166985408, 167116736, 167246656, 167378368, 167508416, 167641024, +167771584, 167903168, 168034112, 168164032, 168295744, 168427456, +168557632, 168688448, 168819136, 168951616, 169082176, 169213504, +169344832, 169475648, 169605952, 169738048, 169866304, 169999552, +170131264, 170262464, 170393536, 170524352, 170655424, 170782016, +170917696, 171048896, 171179072, 171310784, 171439936, 171573184, +171702976, 171835072, 171966272, 172097216, 172228288, 172359232, +172489664, 172621376, 172747712, 172883264, 173014208, 173144512, +173275072, 173407424, 173539136, 173669696, 173800768, 173931712, +174063424, 174193472, 174325696, 174455744, 174586816, 174718912, +174849728, 174977728, 175109696, 175242688, 175374272, 175504832, +175636288, 175765696, 175898432, 176028992, 176159936, 176291264, +176422592, 176552512, 176684864, 176815424, 176946496, 177076544, +177209152, 177340096, 177470528, 177600704, 177731648, 177864256, +177994816, 178126528, 178257472, 178387648, 178518464, 178650176, +178781888, 178912064, 179044288, 179174848, 179305024, 179436736, +179568448, 179698496, 179830208, 179960512, 180092608, 180223808, +180354752, 180485696, 180617152, 180748096, 180877504, 181009984, +181139264, 181272512, 181402688, 181532608, 181663168, 181795136, +181926592, 182057536, 182190016, 182320192, 182451904, 182582336, +182713792, 182843072, 182976064, 183107264, 183237056, 183368384, +183494848, 183631424, 183762752, 183893824, 184024768, 184154816, +184286656, 184417984, 184548928, 184680128, 184810816, 184941248, +185072704, 185203904, 185335616, 185465408, 185596352, 185727296, +185859904, 185989696, 186121664, 186252992, 186383552, 186514112, +186645952, 186777152, 186907328, 187037504, 187170112, 187301824, +187429184, 187562048, 187693504, 187825472, 187957184, 188087104, +188218304, 188349376, 188481344, 188609728, 188743616, 188874304, +189005248, 189136448, 189265088, 189396544, 189528128, 189660992, +189791936, 189923264, 190054208, 190182848, 190315072, 190447424, +190577984, 190709312, 190840768, 190971328, 191102656, 191233472, +191364032, 191495872, 191626816, 191758016, 191888192, 192020288, +192148928, 192282176, 192413504, 192542528, 192674752, 192805952, +192937792, 193068608, 193198912, 193330496, 193462208, 193592384, +193723456, 193854272, 193985984, 194116672, 194247232, 194379712, +194508352, 194641856, 194772544, 194900672, 195035072, 195166016, +195296704, 195428032, 195558592, 195690304, 195818176, 195952576, +196083392, 196214336, 196345792, 196476736, 196607552, 196739008, +196869952, 197000768, 197130688, 197262784, 197394368, 197523904, +197656384, 197787584, 197916608, 198049472, 198180544, 198310208, +198442432, 198573632, 198705088, 198834368, 198967232, 199097792, +199228352, 199360192, 199491392, 199621696, 199751744, 199883968, +200014016, 200146624, 200276672, 200408128, 200540096, 200671168, +200801984, 200933312, 201062464, 201194944, 201326144, 201457472, +201588544, 201719744, 201850816, 201981632, 202111552, 202244032, +202374464, 202505152, 202636352, 202767808, 202898368, 203030336, +203159872, 203292608, 203423296, 203553472, 203685824, 203816896, +203947712, 204078272, 204208192, 204341056, 204472256, 204603328, +204733888, 204864448, 204996544, 205125568, 205258304, 205388864, +205517632, 205650112, 205782208, 205913536, 206044736, 206176192, +206307008, 206434496, 206569024, 206700224, 206831168, 206961856, +207093056, 207223616, 207355328, 207486784, 207616832, 207749056, +207879104, 208010048, 208141888, 208273216, 208404032, 208534336, +208666048, 208796864, 208927424, 209059264, 209189824, 209321792, +209451584, 209582656, 209715136, 209845568, 209976896, 210106432, +210239296, 210370112, 210501568, 210630976, 210763712, 210894272, +211024832, 211156672, 211287616, 211418176, 211549376, 211679296, +211812032, 211942592, 212074432, 212204864, 212334016, 212467648, +212597824, 212727616, 212860352, 212991424, 213120832, 213253952, +213385024, 213515584, 213645632, 213777728, 213909184, 214040128, +214170688, 214302656, 214433728, 214564544, 214695232, 214826048, +214956992, 215089088, 215219776, 215350592, 215482304, 215613248, +215743552, 215874752, 216005312, 216137024, 216267328, 216399296, +216530752, 216661696, 216790592, 216923968, 217054528, 217183168, +217316672, 217448128, 217579072, 217709504, 217838912, 217972672, +218102848, 218233024, 218364736, 218496832, 218627776, 218759104, +218888896, 219021248, 219151936, 219281728, 219413056, 219545024, +219675968, 219807296, 219938624, 220069312, 220200128, 220331456, +220461632, 220592704, 220725184, 220855744, 220987072, 221117888, +221249216, 221378368, 221510336, 221642048, 221772736, 221904832, +222031808, 222166976, 222297536, 222428992, 222559936, 222690368, +222820672, 222953152, 223083968, 223213376, 223345984, 223476928, +223608512, 223738688, 223869376, 224001472, 224132672, 224262848, +224394944, 224524864, 224657344, 224788288, 224919488, 225050432, +225181504, 225312704, 225443776, 225574592, 225704768, 225834176, +225966784, 226097216, 226229824, 226360384, 226491712, 226623424, +226754368, 226885312, 227015104, 227147456, 227278528, 227409472, +227539904, 227669696, 227802944, 227932352, 228065216, 228196288, +228326464, 228457792, 228588736, 228720064, 228850112, 228981056, +229113152, 229243328, 229375936, 229505344, 229636928, 229769152, +229894976, 230030272, 230162368, 230292416, 230424512, 230553152, +230684864, 230816704, 230948416, 231079616, 231210944, 231342016, +231472448, 231603776, 231733952, 231866176, 231996736, 232127296, +232259392, 232388672, 232521664, 232652608, 232782272, 232914496, +233043904, 233175616, 233306816, 233438528, 233569984, 233699776, +233830592, 233962688, 234092224, 234221888, 234353984, 234485312, +234618304, 234749888, 234880832, 235011776, 235142464, 235274048, +235403456, 235535936, 235667392, 235797568, 235928768, 236057152, +236190272, 236322752, 236453312, 236583616, 236715712, 236846528, +236976448, 237108544, 237239104, 237371072, 237501632, 237630784, +237764416, 237895232, 238026688, 238157632, 238286912, 238419392, +238548032, 238681024, 238812608, 238941632, 239075008, 239206336, +239335232, 239466944, 239599168, 239730496, 239861312, 239992384, +240122816, 240254656, 240385856, 240516928, 240647872, 240779072, +240909632, 241040704, 241171904, 241302848, 241433408, 241565248, +241696192, 241825984, 241958848, 242088256, 242220224, 242352064, +242481856, 242611648, 242744896, 242876224, 243005632, 243138496, +243268672, 243400384, 243531712, 243662656, 243793856, 243924544, +244054592, 244187072, 244316608, 244448704, 244580032, 244710976, +244841536, 244972864, 245104448, 245233984, 245365312, 245497792, +245628736, 245759936, 245889856, 246021056, 246152512, 246284224, +246415168, 246545344, 246675904, 246808384, 246939584, 247070144, +247199552, 247331648, 247463872, 247593536, 247726016, 247857088, +247987648, 248116928, 248249536, 248380736, 248512064, 248643008, +248773312, 248901056, 249036608, 249167552, 249298624, 249429184, +249560512, 249692096, 249822784, 249954112, 250085312, 250215488, +250345792, 250478528, 250608704, 250739264, 250870976, 251002816, +251133632, 251263552, 251395136, 251523904, 251657792, 251789248, +251919424, 252051392, 252182464, 252313408, 252444224, 252575552, +252706624, 252836032, 252968512, 253099712, 253227584, 253361728, +253493056, 253623488, 253754432, 253885504, 254017216, 254148032, +254279488, 254410432, 254541376, 254672576, 254803264, 254933824, +255065792, 255196736, 255326528, 255458752, 255589952, 255721408, +255851072, 255983296, 256114624, 256244416, 256374208, 256507712, +256636096, 256768832, 256900544, 257031616, 257162176, 257294272, +257424448, 257555776, 257686976, 257818432, 257949632, 258079552, +258211136, 258342464, 258473408, 258603712, 258734656, 258867008, +258996544, 259127744, 259260224, 259391296, 259522112, 259651904, +259784384, 259915328, 260045888, 260175424, 260308544, 260438336, +260570944, 260700992, 260832448, 260963776, 261092672, 261226304, +261356864, 261487936, 261619648, 261750592, 261879872, 262011968, +262143424, 262274752, 262404416, 262537024, 262667968, 262799296, +262928704, 263061184, 263191744, 263322944, 263454656, 263585216, +263716672, 263847872, 263978944, 264108608, 264241088, 264371648, +264501184, 264632768, 264764096, 264895936, 265024576, 265158464, +265287488, 265418432, 265550528, 265681216, 265813312, 265943488, +266075968, 266206144, 266337728, 266468032, 266600384, 266731072, +266862272, 266993344, 267124288, 267255616, 267386432, 267516992, +267648704, 267777728, 267910592, 268040512, 268172096, 268302784, +268435264, 268566208, 268696256, 268828096, 268959296, 269090368, +269221312, 269352256, 269482688, 269614784, 269745856, 269876416, +270007616, 270139328, 270270272, 270401216, 270531904, 270663616, +270791744, 270924736, 271056832, 271186112, 271317184, 271449536, +271580992, 271711936, 271843136, 271973056, 272105408, 272236352, +272367296, 272498368, 272629568, 272759488, 272891456, 273022784, +273153856, 273284672, 273415616, 273547072, 273677632, 273808448, +273937088, 274071488, 274200896, 274332992, 274463296, 274595392, +274726208, 274857536, 274988992, 275118656, 275250496, 275382208, +275513024, 275643968, 275775296, 275906368, 276037184, 276167872, +276297664, 276429376, 276560576, 276692672, 276822976, 276955072, +277085632, 277216832, 277347008, 277478848, 277609664, 277740992, +277868608, 278002624, 278134336, 278265536, 278395328, 278526784, +278657728, 278789824, 278921152, 279052096, 279182912, 279313088, +279443776, 279576256, 279706048, 279838528, 279969728, 280099648, +280230976, 280361408, 280493632, 280622528, 280755392, 280887104, +281018176, 281147968, 281278912, 281411392, 281542592, 281673152, +281803712, 281935552, 282066496, 282197312, 282329024, 282458816, +282590272, 282720832, 282853184, 282983744, 283115072, 283246144, +283377344, 283508416, 283639744, 283770304, 283901504, 284032576, +284163136, 284294848, 284426176, 284556992, 284687296, 284819264, +284950208, 285081536] +``` diff --git a/public/content/translations/vi/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md b/public/content/translations/vi/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md new file mode 100644 index 00000000000..44a53fdcc9d --- /dev/null +++ b/public/content/translations/vi/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md @@ -0,0 +1,42 @@ +--- +title: "Thuật toán khai thác" +description: "Một cái nhìn chi tiết về các thuật toán được sử dụng cho việc đào Ethereum." +lang: vi +--- + + + + + +Bằng chứng làm việc không còn là cơ chế đồng thuận nền tảng của Ethereum, nghĩa là việc khai thác đã bị tắt. Thay vào đó, Ethereum được bảo mật bởi các trình xác thực đặt cọc ETH. Bạn có thể bắt đầu đặt cọc ETH của mình ngay từ hôm nay. Đọc thêm về sự kiện hợp nhất, Bằng chứng cổ phần và Cổ phần. Trang này chỉ nhằm mục đích tham khảo lịch sử. + + + + +Việc đào Ethereum đã sử dụng một thuật toán gọi là Ethash. Ý tưởng cơ bản của thuật toán là thợ đào sẽ cố gắng tìm một giá trị nonce đầu vào bằng cách tính toán brute force, sao cho giá trị băm (hash) thu được nhỏ hơn một ngưỡng được xác định bởi độ khó (difficulty) đã tính toán. Mức độ khó này có thể được điều chỉnh linh hoạt, cho phép việc tạo khối diễn ra theo chu kỳ ổn định. + +## Điều kiện tiên quyết {#prerequisites} + +Để hiểu rõ hơn về trang này, chúng tôi khuyên bạn nên đọc trước về [sự đồng thuận bằng chứng công việc](/developers/docs/consensus-mechanisms/pow) và [khai thác](/developers/docs/consensus-mechanisms/pow/mining). + +## Dagger Hashimoto {#dagger-hashimoto} + +Dagger Hashimoto là một thuật toán nghiên cứu tiền thân cho việc đào Ethereum, sau đó đã được thay thế bởi Ethash. Đây là sự kết hợp của hai thuật toán khác nhau: Dagger và Hashimoto. Nó chỉ từng tồn tại như một bản thử nghiệm nghiên cứu và đã được thay thế bởi Ethash khi Ethereum Mainnet ra mắt. + +[Dagger](http://www.hashcash.org/papers/dagger.html) liên quan đến việc tạo ra một [Đồ thị có hướng không tuần hoàn](https://en.wikipedia.org/wiki/Directed_acyclic_graph), các lát cắt ngẫu nhiên của đồ thị này sẽ được băm lại với nhau. Nguyên tắc cốt lõi là mỗi giá trị nonce chỉ yêu cầu một phần nhỏ của toàn bộ cây dữ liệu lớn. Việc tính toán lại cây con cho mỗi nonce là không khả thi đối với việc đào – do đó cần phải lưu trữ cây dữ liệu – nhưng lại chấp nhận được khi chỉ cần xác minh một nonce duy nhất. Dagger được thiết kế để trở thành một giải pháp thay thế cho các thuật toán hiện có như Scrypt, vốn “nặng bộ nhớ” nhưng khó xác minh khi mức độ nặng bộ nhớ của chúng tăng lên đến mức an toàn thực sự. Tuy nhiên, Dagger dễ bị ảnh hưởng bởi tăng tốc phần cứng bộ nhớ chia sẻ và đã bị loại bỏ để nhường chỗ cho các hướng nghiên cứu khác. + +[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) là một thuật toán bổ sung khả năng chống ASIC bằng cách phụ thuộc vào I/O (tức là, việc đọc bộ nhớ là yếu tố giới hạn trong quá trình khai thác). Lý thuyết đặt ra rằng RAM sẵn có hơn so với năng lực tính toán; hàng tỷ đô la nghiên cứu đã được đầu tư vào việc tối ưu hóa RAM cho các trường hợp sử dụng khác nhau, vốn thường liên quan đến các mô hình truy cập gần như ngẫu nhiên (do đó gọi là “bộ nhớ truy cập ngẫu nhiên” – RAM). Do đó, RAM hiện có có khả năng ở mức gần tối ưu để đánh giá thuật toán. Hashimoto sử dụng blockchain như một nguồn dữ liệu, đồng thời đáp ứng các điều kiện (1) và (3) nêu trên. + +Dagger-Hashimoto đã sử dụng các phiên bản chỉnh sửa của thuật toán Dagger và Hashimoto. Điểm khác biệt giữa Dagger Hashimoto và Hashimoto là thay vì sử dụng blockchain như một nguồn dữ liệu, Dagger Hashimoto dùng một tập dữ liệu được tạo tùy chỉnh, được cập nhật dựa trên dữ liệu khối sau mỗi N khối. Tập dữ liệu được tạo bằng thuật toán Dagger, cho phép tính toán hiệu quả một tập con dành riêng cho từng nonce trong thuật toán xác minh light client. Điểm khác biệt giữa Dagger Hashimoto và Dagger là, không giống như trong Dagger ban đầu, tập dữ liệu được dùng để truy vấn khối là bán cố định, chỉ được cập nhật theo định kỳ (ví dụ: mỗi tuần một lần). Điều này có nghĩa là phần công sức để tạo tập dữ liệu gần như bằng không, do đó lập luận của Sergio Lerner về việc tăng tốc nhờ bộ nhớ chia sẻ trở nên không đáng kể. + +Thông tin thêm về [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto). + +## Ethash {#ethash} + +Ethash là thuật toán đào thực sự đã được sử dụng trên Ethereum Mainnet, dưới kiến trúc proof-of-work hiện đã bị loại bỏ. Ethash thực chất là tên mới được đặt cho một phiên bản cụ thể của Dagger-Hashimoto sau khi thuật toán này được cập nhật đáng kể, trong khi vẫn kế thừa các nguyên tắc cơ bản của tiền thân nó. Mạng chính Ethereum chỉ từng sử dụng Ethash - Dagger Hashimoto là một phiên bản nghiên cứu và phát triển (R&D) của thuật toán khai thác đã bị thay thế trước khi việc khai thác bắt đầu trên Mạng chính Ethereum. + +[Thông tin thêm về Ethash](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash). + +## Đọc thêm {#further-reading} + +_Biết về nguồn lực cộng đồng đã giúp đỡ bạn? Chỉnh sửa trang này và bổ sung!_ diff --git a/public/content/translations/vi/developers/docs/dapps/index.md b/public/content/translations/vi/developers/docs/dapps/index.md new file mode 100644 index 00000000000..9d1dd488f2a --- /dev/null +++ b/public/content/translations/vi/developers/docs/dapps/index.md @@ -0,0 +1,96 @@ +--- +title: "Giới thiệu kỹ thuật về ứng dụng phi tập trung" +description: +lang: vi +--- + +Một ứng dụng phi tập trung (dapp) là một ứng dụng được xây dựng trên một mạng phi tập trung kết hợp một [hợp đồng thông minh](/developers/docs/smart-contracts/) và một giao diện người dùng frontend. Trên Ethereum, các smartcontract có thể truy cập và minh bạch giống như các API mở, Dapp của bạn thậm chí có thể bao gồm một smartcontract mà người khác đã viết. + +## Điều kiện tiên quyết {#prerequisites} + +Trước khi tìm hiểu về các ứng dụng phi tập trung, bạn nên nắm những [kiến thức cơ bản về chuỗi khối](/developers/docs/intro-to-ethereum/) và đọc về mạng Ethereum cũng như cách nó được phi tập trung hóa. + +## Định nghĩa về dapp {#definition-of-a-dapp} + +Một dapp có backend của nó chạy trên một mạng phi tập trung ngang hàng. Ngược lại điều này với một ứng dụng có backend đang chạy trên các máy chủ tập trung. + +Một Dapp có thể có frontend và giao diện người dùng được viết bằng bất cứ ngôn ngữ nào ( giống như một app) để thực hiện các hành động tới backend. Hơn nữa, giao diện frontend của nó có thể được lưu trữ trên bộ nhớ phi tập trung như [IPFS](https://ipfs.io/). + +- **Phi tập trung** - các ứng dụng phi tập trung hoạt động trên Ethereum, một nền tảng phi tập trung công khai, mở, nơi không một cá nhân hay tổ chức nào có quyền kiểm soát +- **Tất định** - các ứng dụng phi tập trung thực hiện cùng một chức năng bất kể môi trường mà chúng được thực thi +- **Hoàn thiện Turing** - các ứng dụng phi tập trung có thể thực hiện bất kỳ hành động nào nếu được cung cấp đủ các tài nguyên cần thiết +- **Cô lập** - các ứng dụng phi tập trung được thực thi trong một môi trường ảo được gọi là Máy ảo Ethereum (EVM), do đó, nếu hợp đồng thông minh có lỗi, nó sẽ không cản trở hoạt động bình thường của mạng chuỗi khối + +### Về hợp đồng thông minh {#on-smart-contracts} + +Để giới thiệu Dapps, chúng ta cần giới thiệu các smartcontract- một backend của dapp vì không có thuật ngữ nào tốt hơn để giới thiệu. Để có cái nhìn tổng quan chi tiết, hãy chuyển đến phần của chúng tôi về [hợp đồng thông minh](/developers/docs/smart-contracts/). + +Smartcontract là những code thực thi trên Ethereum blockchain và chạy chính xác như được lập trình. Sau khi các smart contract được triển khai trên network, bạn không thể thay đổi. Dapps có thể được phân cấp vì chúng được kiểm soát bởi logic được ghi trong contract, không phải là một cá nhân hay một tổ chức. Bạn cần thiết kế contract của mình rất cẩn thận và kiểm tra chúng một cách kĩ lưỡng. + +## Lợi ích của việc phát triển ứng dụng phi tập trung {#benefits-of-dapp-development} + +- **Không có thời gian chết** – Một khi hợp đồng thông minh được triển khai trên chuỗi khối, toàn bộ mạng lưới sẽ luôn có thể phục vụ các máy khách muốn tương tác với hợp đồng. Do đó, các tác nhân độc hại không thể khởi động các cuộc tấn công từ chối dịch vụ nhằm vào các dapp riêng lẻ. +- **Quyền riêng tư** – Bạn không cần cung cấp danh tính trong thế giới thực để triển khai hoặc tương tác với một ứng dụng phi tập trung. +- **Chống kiểm duyệt** – Không một thực thể đơn lẻ nào trên mạng có thể chặn người dùng gửi giao dịch, triển khai các ứng dụng phi tập trung, hoặc đọc dữ liệu từ chuỗi khối. +- **Toàn vẹn dữ liệu tuyệt đối** – Dữ liệu được lưu trữ trên chuỗi khối là bất biến và không thể chối cãi, nhờ vào các nguyên hàm mật mã. Các tác nhân độc hại không thể giả mạo các giao dịch hoặc dữ liệu khác đã được công khai. +- **Tính toán phi tín nhiệm/hành vi có thể xác minh** – Các hợp đồng thông minh có thể được phân tích và được đảm bảo thực thi theo những cách có thể dự đoán được mà không cần phải tin tưởng vào một cơ quan trung ương. Điều này không đúng trong các mô hình truyền thống, ví dụ: Khi sử dụng các ngân hàng online, chúng ta phải tin tưởng các tổ chức tài chính sẽ không sử dụng sai số liệu tài chính của chúng ta, giả mạo hồ sơ hoặc bị tấn công. + +## Nhược điểm của việc phát triển ứng dụng phi tập trung {#drawbacks-of-dapp-development} + +- **Bảo trì** – Các ứng dụng phi tập trung có thể khó bảo trì hơn vì mã và dữ liệu được công bố trên chuỗi khối khó sửa đổi hơn. Các developes khó có thể update dapp của họ sau khi chúng được release, ngay cả khi lỗi hoặc rủi ro bảo mật được xác định trong phiên bản cũ. +- **Chi phí hiệu suất** – Có một chi phí hiệu suất rất lớn, và việc thay đổi quy mô là thực sự khó khăn. Để đạt được tính bảo mật, tính toàn vẹn và tính minh bạch mà Ethereum mong muốn thì các node đều chaỵ và lưu trữ mọi giao dịch. Cơ chế đồng thuận bằng chứng cổ phần cũng cần có thời gian. +- **Tắc nghẽn mạng** – Khi một ứng dụng phi tập trung sử dụng quá nhiều tài nguyên tính toán, toàn bộ mạng sẽ bị tắc nghẽn. Hiện tại, theo tính toán thì network có thể xử lý khoảng 10-15 giao dịch mỗi giây. Nếu các yêu cầu giao dịch nhanh hơn mức này, nhóm các giao dịch chưa được xử lý sẽ nhanh chóng tăng vọt. +- **Trải nghiệm người dùng** – Có thể khó hơn để thiết kế các trải nghiệm thân thiện với người dùng vì người dùng cuối thông thường có thể thấy quá khó để thiết lập một bộ công cụ cần thiết để tương tác với chuỗi khối một cách thực sự an toàn. +- **Tập trung hóa** – Các giải pháp thân thiện với người dùng và nhà phát triển được xây dựng trên lớp cơ sở của Ethereum cuối cùng có thể trông giống như các dịch vụ tập trung. Ví dụ: các dịch vụ như vậy có thể lưu trữ khóa hoặc thông tin nhạy cảm khác ở phía máy chủ, phục vụ giao diện người dùng sử dụng máy chủ tập trung hoặc chạy logic nghiệp vụ quan trọng trên máy chủ tập trung trước khi ghi vào chuỗi khối. Tập trung hóa loại bỏ nhiều (nếu không phải tất cả) những lợi thế của blockchain so với mô hình truyền thống. + +## Tìm hiểu thêm từ video trực quan? Người học qua hình ảnh {#visual-learner} + + + +## Các công cụ để tạo các ứng dụng phi tập trung {#dapp-tools} + +**Scaffold-ETH _- Nhanh chóng thử nghiệm với Solidity bằng một giao diện frontend có thể tự điều chỉnh theo hợp đồng thông minh của bạn._** + +- [GitHub](https://github.com/scaffold-eth/scaffold-eth-2) +- [Ví dụ về ứng dụng phi tập trung](https://punkwallet.io/) + +**Create Eth App _- Tạo các ứng dụng chạy trên Ethereum chỉ với một lệnh._** + +- [GitHub](https://github.com/paulrberg/create-eth-app) + +**One Click Dapp _- Công cụ FOSS để tạo giao diện frontend cho ứng dụng phi tập trung từ một [ABI](/glossary/#abi)._** + +- [oneclickdapp.com](https://oneclickdapp.com) +- [GitHub](https://github.com/oneclickdapp/oneclickdapp-v1) + +**Etherflow _- Công cụ FOSS cho các nhà phát triển Ethereum để kiểm tra nút của họ, cũng như soạn và gỡ lỗi các lệnh gọi RPC từ trình duyệt._** + +- [etherflow.quiknode.io](https://etherflow.quiknode.io/) +- [GitHub](https://github.com/abunsen/etherflow) + +**thirdweb _- Các bộ SDK cho mọi ngôn ngữ, hợp đồng thông minh, công cụ, và cơ sở hạ tầng cho việc phát triển web3._** + +- [Trang chủ](https://thirdweb.com/) +- [Tài liệu tham khảo](https://portal.thirdweb.com/) +- [GitHub](https://github.com/thirdweb-dev/) + +**Crossmint _- Nền tảng phát triển web3 cấp doanh nghiệp để triển khai các hợp đồng thông minh, cho phép thanh toán bằng thẻ tín dụng và đa chuỗi, và sử dụng các API để tạo, phân phối, bán, lưu trữ và chỉnh sửa NFT._** + +- [crossmint.com](https://www.crossmint.com) +- [Tài liệu tham khảo](https://docs.crossmint.com) +- [Discord](https://discord.com/invite/crossmint) + +## Đọc thêm {#further-reading} + +- [Khám phá các ứng dụng phi tập trung](/apps) +- [Kiến trúc của một ứng dụng Web 3.0](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _Preethi Kasireddy_ +- [Hướng dẫn về các ứng dụng phi tập trung năm 2021](https://limechain.tech/blog/what-are-dapps-the-2021-guide/) - _LimeChain_ +- [Ứng dụng phi tập trung là gì?](https://www.gemini.com/cryptopedia/decentralized-applications-defi-dapps) - _Gemini_ +- [Các ứng dụng phi tập trung phổ biến](https://www.alchemy.com/dapps) - _Alchemy_ + +_Biết về nguồn lực cộng đồng đã giúp đỡ bạn? Chỉnh sửa trang này và bổ sung!_ + +## Các chủ đề liên quan {#related-topics} + +- [Giới thiệu về bộ công cụ Ethereum](/developers/docs/ethereum-stack/) +- [Các khung phát triển](/developers/docs/frameworks/) diff --git a/public/content/translations/vi/developers/docs/data-and-analytics/block-explorers/index.md b/public/content/translations/vi/developers/docs/data-and-analytics/block-explorers/index.md new file mode 100644 index 00000000000..284302b246c --- /dev/null +++ b/public/content/translations/vi/developers/docs/data-and-analytics/block-explorers/index.md @@ -0,0 +1,254 @@ +--- +title: "Trình duyệt khối" +description: "Giới thiệu về trình khám phá khối, thông tin của bạn ở trong thế giới của dữ liệu blockchain, nơi bạn có thể truy vấn thông tin về giao dịch, tài khoản, liên lạc và nhiều hơn nữa." +lang: vi +sidebarDepth: 3 +--- + +Các trình duyệt khối là cổng thông tin của bạn đến dữ liệu của Ethereum. Bạn có thể sử dụng chúng để xem dữ liệu theo thời gian thực về các khối, giao dịch, người xác thực, tài khoản và các hoạt động trên chuỗi khác. + +## Điều kiện tiên quyết {#prerequisites} + +Bạn nên hiểu các khái niệm cơ bản về Ethereum để có thể hiểu được dữ liệu mà trình duyệt khối cung cấp cho bạn. Bắt đầu với [phần giới thiệu về Ethereum](/developers/docs/intro-to-ethereum/). + +## Các dịch vụ {#services} + +- [Etherscan](https://etherscan.io/) -_Cũng có sẵn bằng tiếng Trung, tiếng Hàn, tiếng Nga và tiếng Nhật_ +- [3xpl](https://3xpl.com/ethereum) +- [Beaconcha.in](https://beaconcha.in/) +- [Blockchair](https://blockchair.com/ethereum) -_Cũng có sẵn bằng tiếng Tây Ban Nha, tiếng Pháp, tiếng Ý, tiếng Hà Lan, tiếng Bồ Đào Nha, tiếng Nga, tiếng Trung và tiếng Farsi_ +- [Blockscout](https://eth.blockscout.com/) +- [Chainlens](https://www.chainlens.com/) +- [Trình duyệt khối DexGuru](https://ethereum.dex.guru/) +- [Etherchain](https://www.etherchain.org/) +- [Ethplorer](https://ethplorer.io/) -_Cũng có sẵn bằng tiếng Trung, tiếng Tây Ban Nha, tiếng Pháp, tiếng Thổ Nhĩ Kỳ, tiếng Nga, tiếng Hàn và tiếng Việt_ +- [EthVM](https://www.ethvm.com/) +- [OKLink](https://www.oklink.com/eth) +- [Ethseer](https://ethseer.io) + +## Các công cụ mã nguồn mở {#open-source-tools} + +- [Otterscan](https://otterscan.io/) +- [lazy-etherscan](https://github.com/woxjro/lazy-etherscan) + +## Dữ liệu {#data} + +Ethereum được thiết kế minh bạch để mọi thứ đều có thể kiểm chứng được. Các trình duyệt khối cung cấp một giao diện để nhận thông tin này. Và điều này dành cho cả mạng chính Ethereum và các mạng thử nghiệm, phòng khi bạn cần dữ liệu đó. Dữ liệu được chia thành dữ liệu thực thi và dữ liệu đồng thuận. Dữ liệu thực thi đề cập đến các giao dịch đã được thực hiện trong một khối cụ thể. Dữ liệu đồng thuận đề cập đến chính các khối và những người xác thực đã đề xuất chúng. + +Đây là bản tóm tắt các loại dữ liệu bạn có thể nhận được từ một trình duyệt khối. + +### Dữ liệu thực thi {#execution-data} + +Các khối mới được thêm vào Ethereum sau mỗi 12 giây (trừ khi người đề xuất khối bỏ lỡ lượt của mình), do đó, một luồng dữ liệu gần như không đổi được thêm vào các trình duyệt khối. Các khối chứa rất nhiều dữ liệu quan trọng mà bạn có thể thấy hữu ích: + +**Dữ liệu tiêu chuẩn** + +- Chiều cao khối - Số khối và độ dài của chuỗi khối (tính bằng khối) khi tạo khối hiện tại +- Dấu thời gian - Thời điểm một khối được đề xuất +- Các giao dịch - Số lượng giao dịch có trong khối +- Người nhận phí - Địa chỉ đã nhận tiền boa phí gas từ các giao dịch +- Phần thưởng khối - Lượng ETH được trao cho người xác thực đã đề xuất khối đó +- Kích thước - Kích thước của dữ liệu trong khối (được đo bằng byte) +- Gas đã sử dụng - Tổng số đơn vị gas được sử dụng bởi các giao dịch trong khối +- Giới hạn gas - Tổng giới hạn gas được đặt bởi các giao dịch trong khối +- Phí cơ bản mỗi gas - Hệ số nhân tối thiểu cần thiết để một giao dịch được đưa vào một khối +- Phí bị đốt - Lượng ETH bị đốt trong khối +- Dữ liệu bổ sung - Mọi dữ liệu bổ sung mà người xây dựng đã đưa vào khối + +**Dữ liệu nâng cao** + +- Hàm băm - Hàm băm mã hóa đại diện cho tiêu đề khối (mã định danh duy nhất của khối) +- Hàm băm mẹ - Hàm băm của khối có trước khối hiện tại +- StateRoot - Hàm băm gốc của cây Merkle lưu trữ toàn bộ trạng thái của hệ thống + +### Gas {#gas} + +Các trình duyệt khối không chỉ cung cấp cho bạn dữ liệu về việc sử dụng Gas trong các giao dịch và khối, mà một số còn cung cấp cho bạn thông tin về giá gas hiện tại của mạng. Điều này sẽ giúp bạn hiểu việc sử dụng mạng, gửi các giao dịch an toàn và không chi tiêu quá nhiều cho gas. Hãy tìm các API có thể giúp bạn đưa thông tin này vào giao diện sản phẩm của mình. Dữ liệu dành riêng cho gas bao gồm: + +- Ước tính các đơn vị gas cần thiết cho một giao dịch an toàn nhưng chậm (+ giá và thời gian ước tính) +- Ước tính các đơn vị gas cần thiết cho một giao dịch trung bình (+ giá và thời gian ước tính) +- Ước tính các đơn vị gas cần thiết cho một giao dịch nhanh (+ giá và thời gian ước tính) +- Thời gian xác nhận trung bình dựa trên giá gas +- Các hợp đồng đang tiêu thụ gas - nói cách khác, các sản phẩm phổ biến đang được sử dụng nhiều trên mạng +- Các tài khoản đang chi tiêu gas - nói cách khác, những người dùng mạng thường xuyên + +### Các giao dịch {#transactions} + +Các trình duyệt khối đã trở thành một nơi phổ biến để mọi người theo dõi tiến trình giao dịch của họ. Đó là vì mức độ chi tiết bạn có thể nhận được mang lại sự chắc chắn hơn. Dữ liệu giao dịch bao gồm: + +**Dữ liệu tiêu chuẩn** + +- Hàm băm giao dịch - Một hàm băm được tạo khi giao dịch được gửi đi +- Trạng thái - Chỉ báo liệu giao dịch đang chờ xử lý, không thành công hay đã thành công +- Khối - Khối mà giao dịch đã được đưa vào +- Dấu thời gian - Thời điểm một giao dịch được đưa vào một khối do một người xác thực đề xuất +- Từ - Địa chỉ của tài khoản đã gửi giao dịch +- Đến - Địa chỉ của người nhận hoặc hợp đồng thông minh mà giao dịch tương tác +- Các token đã chuyển - Danh sách các token đã được chuyển như một phần của giao dịch +- Giá trị - Tổng giá trị ETH đang được chuyển +- Phí giao dịch - Số tiền trả cho người xác thực để xử lý giao dịch (được tính bằng giá gas\*gas đã sử dụng) + +**Dữ liệu nâng cao** + +- Giới hạn gas - Số đơn vị gas tối đa mà giao dịch này có thể tiêu thụ +- Gas đã sử dụng - Lượng đơn vị gas thực tế mà giao dịch đã tiêu thụ +- Giá gas - Giá được đặt cho mỗi đơn vị gas +- Nonce - Số giao dịch cho địa chỉ `from` (lưu ý rằng số này bắt đầu từ 0, do đó, nonce `100` thực sự sẽ là giao dịch thứ 101 được gửi bởi tài khoản này) +- Dữ liệu đầu vào - Bất kỳ thông tin bổ sung nào được yêu cầu bởi giao dịch + +### Các tài khoản {#accounts} + +Có rất nhiều dữ liệu bạn có thể truy cập về một tài khoản. Đây là lý do tại sao thường nên sử dụng nhiều tài khoản để tài sản và giá trị của bạn không thể bị theo dõi dễ dàng. Cũng có một số giải pháp đang được phát triển để làm cho các giao dịch và hoạt động tài khoản trở nên riêng tư hơn. Nhưng đây là dữ liệu có sẵn cho các tài khoản: + +**Tài khoản người dùng** + +- Địa chỉ tài khoản - Địa chỉ công khai bạn có thể sử dụng để gửi tiền đến +- Số dư ETH - Lượng ETH được liên kết với tài khoản đó +- Tổng giá trị ETH - Giá trị của ETH +- Token - Các token được liên kết với tài khoản và giá trị của chúng +- Lịch sử giao dịch - Danh sách tất cả các giao dịch mà tài khoản này là người gửi hoặc người nhận + +**Hợp đồng thông minh** + +Các tài khoản hợp đồng thông minh có tất cả dữ liệu mà một tài khoản người dùng sẽ có, nhưng một số trình duyệt khối thậm chí sẽ hiển thị một số thông tin mã. Các ví dụ bao gồm: + +- Người tạo hợp đồng - Địa chỉ đã triển khai hợp đồng lên Mainnet +- Giao dịch tạo - Giao dịch bao gồm việc triển khai lên Mainnet +- Mã nguồn - Mã Solidity hoặc Vyper của hợp đồng thông minh +- ABI hợp đồng - Giao diện nhị phân ứng dụng của hợp đồng—các lệnh gọi mà hợp đồng thực hiện và dữ liệu nhận được +- Mã tạo hợp đồng - Bytecode đã biên dịch của hợp đồng thông minh—được tạo khi bạn biên dịch một hợp đồng thông minh được viết bằng Solidity hoặc Vyper, v.v. +- Sự kiện hợp đồng - Lịch sử các phương thức được gọi trong hợp đồng thông minh—về cơ bản là một cách để xem hợp đồng đang được sử dụng như thế nào và tần suất ra sao + +### Token {#tokens} + +Token là một loại hợp đồng nên chúng sẽ có dữ liệu tương tự như một hợp đồng thông minh. Nhưng vì chúng có giá trị và có thể được giao dịch nên chúng có các điểm dữ liệu bổ sung: + +- Loại - Cho dù chúng là ERC-20, ERC-721 hay một tiêu chuẩn token khác +- Giá - Nếu là token ERC-20, chúng sẽ có giá trị thị trường hiện tại +- Vốn hóa thị trường - Nếu là token ERC-20, chúng sẽ có vốn hóa thị trường (tính bằng giá\*tổng nguồn cung) +- Tổng nguồn cung - Số lượng token đang lưu hành +- Người nắm giữ - Số lượng địa chỉ nắm giữ token +- Lượt chuyển - Số lần token đã được chuyển giữa các tài khoản +- Lịch sử giao dịch - Lịch sử của tất cả các giao dịch bao gồm token +- Địa chỉ hợp đồng - Địa chỉ của token đã được triển khai lên Mainnet +- Số thập phân - Token ERC-20 có thể chia được và có các chữ số thập phân + +### Mạng {#network} + +Một số dữ liệu khối quan tâm đến sức khỏe của Ethereum một cách toàn diện hơn. + +- Tổng số giao dịch - Số lượng giao dịch kể từ khi Ethereum được tạo +- Giao dịch mỗi giây - Số lượng giao dịch có thể xử lý trong một giây +- Giá ETH - Định giá hiện tại của 1 ETH +- Tổng cung ETH - Số lượng ETH đang lưu hành—hãy nhớ ETH mới được tạo ra với việc tạo ra mọi khối dưới dạng phần thưởng khối +- Vốn hóa thị trường - Tính toán giá\*nguồn cung + +## Dữ liệu lớp đồng thuận {#consensus-layer-data} + +### Epoch {#epoch} + +Vì lý do bảo mật, các ủy ban người xác thực ngẫu nhiên được tạo ra vào cuối mỗi epoch (mỗi 6,4 phút). Dữ liệu epoch bao gồm: + +- Số epoch +- Trạng thái hoàn tất - Liệu epoch đã được hoàn tất hay chưa (Có/Không) +- Thời gian - Thời điểm epoch kết thúc +- Sự chứng thực - Số lượng chứng thực trong epoch (phiếu bầu cho các khối trong các slot) +- Tiền gửi - Số lượng tiền gửi ETH có trong epoch (người xác thực phải đặt cược ETH để trở thành người xác thực) +- Việc phạt - Số lượng hình phạt dành cho người đề xuất khối hoặc người chứng thực +- Sự tham gia bỏ phiếu - Lượng ETH đã đặt cược được sử dụng để chứng thực các khối +- Người xác thực - Số lượng người xác thực hoạt động trong epoch +- Số dư trung bình của người xác thực - Số dư trung bình của những người xác thực đang hoạt động +- Slot - Số lượng slot có trong epoch (các slot bao gồm một khối hợp lệ) + +### Slot {#slot} + +Các slot là cơ hội để tạo khối, dữ liệu có sẵn cho mỗi slot bao gồm: + +- Epoch - Epoch mà trong đó slot có hiệu lực +- Số slot +- Trạng thái - Trạng thái của slot (Được đề xuất/Bị bỏ lỡ) +- Thời gian - Dấu thời gian của slot +- Người đề xuất - Người xác thực đã đề xuất khối cho slot +- Gốc khối - Gốc cây băm của BeaconBlock +- Gốc mẹ - Hàm băm của khối có trước +- Gốc trạng thái - Gốc cây băm của BeaconState +- Chữ ký +- Tiết lộ Randao +- Graffiti - Một người đề xuất khối có thể bao gồm một thông báo dài 32 byte trong đề xuất khối của mình +- Dữ liệu thực thi + - Hàm băm khối + - Số lượng tiền gửi + - Gốc tiền gửi +- Sự chứng thực - Số lượng chứng thực cho khối trong slot này +- Tiền gửi - Số lượng tiền gửi trong slot này +- Thoát tự nguyện - Số lượng người xác thực đã rời đi trong slot +- Việc phạt - Số lượng hình phạt dành cho người đề xuất khối hoặc người chứng thực +- Phiếu bầu - Những người xác thực đã bỏ phiếu cho khối trong slot này + +### Các khối {#blocks-1} + +Bằng chứng cổ phần chia thời gian thành các slot và epoch. Vì vậy, điều đó có nghĩa là có dữ liệu mới! + +- Người đề xuất - Người xác thực được chọn theo thuật toán để đề xuất khối mới +- Epoch - Epoch mà trong đó khối được đề xuất +- Slot - Slot mà trong đó khối được đề xuất +- Sự chứng thực - Số lượng chứng thực có trong slot—các chứng thực giống như các phiếu bầu cho thấy khối đã sẵn sàng để đi đến Chuỗi Beacon + +### Người xác thực {#validators} + +Những người xác thực chịu trách nhiệm đề xuất các khối và chứng thực chúng trong các slot. + +- Số người xác thực - Số duy nhất đại diện cho người xác thực +- Số dư hiện tại - Số dư của người xác thực bao gồm cả phần thưởng +- Số dư hiệu dụng - Số dư của người xác thực được sử dụng để đặt cược +- Thu nhập - Phần thưởng hoặc hình phạt mà người xác thực nhận được +- Trạng thái - Liệu người xác thực hiện có đang trực tuyến và hoạt động hay không +- Hiệu quả chứng thực - Thời gian trung bình để các chứng thực của người xác thực được đưa vào chuỗi +- Đủ điều kiện kích hoạt - Ngày (và epoch) khi người xác thực có thể xác thực +- Hoạt động từ - Ngày (và epoch) khi người xác thực bắt đầu hoạt động +- Các khối đã đề xuất - Khối mà người xác thực đã đề xuất +- Sự chứng thực - Các chứng thực mà người xác thực đã cung cấp +- Tiền gửi - Địa chỉ gửi, hàm băm giao dịch, số khối, dấu thời gian, số tiền và trạng thái của khoản tiền gửi đặt cược do người xác thực thực hiện + +### Sự chứng thực {#attestations} + +Sự chứng thực là các phiếu bầu "đồng ý" để đưa các khối vào chuỗi. Dữ liệu của họ liên quan đến một bản ghi về sự chứng thực và những người xác thực đã chứng thực + +- Slot - Slot mà trong đó sự chứng thực diễn ra +- Chỉ số ủy ban - Chỉ số của ủy ban tại một slot nhất định +- Các bit tổng hợp - Đại diện cho sự chứng thực tổng hợp của tất cả những người xác thực tham gia vào việc chứng thực +- Người xác thực - Những người xác thực đã cung cấp chứng thực +- Gốc khối Beacon - Trỏ đến khối mà những người xác thực đang chứng thực +- Nguồn - Trỏ đến epoch hợp lý mới nhất +- Mục tiêu - Trỏ đến ranh giới epoch mới nhất +- Chữ ký + +### Mạng {#network-1} + +Dữ liệu cấp cao nhất của lớp đồng thuận bao gồm những điều sau: + +- Epoch hiện tại +- Slot hiện tại +- Người xác thực đang hoạt động - Số lượng người xác thực đang hoạt động +- Người xác thực đang chờ - Số lượng người xác thực đang chờ để được kích hoạt +- ETH đã đặt cược - Lượng ETH đã đặt cược trong mạng +- Số dư trung bình - Số dư ETH trung bình của những người xác thực + +## Trình duyệt khối {#block-explorers} + +- [Etherscan](https://etherscan.io/) - một trình duyệt khối bạn có thể sử dụng để tìm nạp dữ liệu cho Mainnet và mạng thử nghiệm của Ethereum +- [3xpl](https://3xpl.com/ethereum) - một trình duyệt Ethereum mã nguồn mở không có quảng cáo cho phép tải xuống các bộ dữ liệu của nó +- [Beaconcha.in](https://beaconcha.in/) - một trình duyệt khối mã nguồn mở cho Mainnet và mạng thử nghiệm của Ethereum +- [Blockchair](https://blockchair.com/ethereum) - trình duyệt Ethereum riêng tư nhất. Cũng dùng để sắp xếp và lọc dữ liệu (mempool) +- [Etherchain](https://www.etherchain.org/) - một trình duyệt khối cho Mainnet của Ethereum +- [Ethplorer](https://ethplorer.io/) - một trình duyệt khối tập trung vào các token cho Mainnet của Ethereum và mạng thử nghiệm Kovan + +## Đọc thêm {#further-reading} + +_Biết về nguồn lực cộng đồng đã giúp đỡ bạn? Chỉnh sửa trang này và bổ sung!_ + +## Các chủ đề liên quan {#related-topics} + +- [Giao dịch](/developers/docs/transactions/) +- [Tài khoản](/developers/docs/accounts/) +- [Các mạng](/developers/docs/networks/) diff --git a/public/content/translations/vi/developers/docs/data-and-analytics/index.md b/public/content/translations/vi/developers/docs/data-and-analytics/index.md new file mode 100644 index 00000000000..d477a9dc4cf --- /dev/null +++ b/public/content/translations/vi/developers/docs/data-and-analytics/index.md @@ -0,0 +1,72 @@ +--- +title: "Dữ liệu và phân tích" +description: "Cách thu thập dữ liệu onchain và phân tích để sử dụng trong các ứng dụng phi tập trung của bạn" +lang: vi +--- + +## Giới thiệu {#Introduction} + +Khi việc sử dụng mạng ngày càng tăng, sẽ có một lượng lớn thông tin giá trị hơn trong dữ liệu onchain. Khi khối lượng dữ liệu tăng nhanh, việc tính toán và tổng hợp thông tin này để báo cáo hoặc làm cho một dapp có thể trở thành công việc tốn thời gian và công sức. + +Tận dụng các nhà cung cấp dữ liệu hiện có có thể tăng tốc độ phát triển, tạo ra kết quả chính xác hơn và giảm thiểu nỗ lực bảo trì liên tục. Điều này sẽ giúp cho một đội ngũ tập trung vào chức năng chính mà dự án của họ đang cố gắng cung cấp. + +## Điều kiện tiên quyết {#prerequisites} + +Bạn nên hiểu khái niệm cơ bản về [Trình duyệt khối](/developers/docs/data-and-analytics/block-explorers/) để hiểu rõ hơn về cách sử dụng chúng trong bối cảnh phân tích dữ liệu. Ngoài ra, hãy tự làm quen với khái niệm về một [chỉ mục](/glossary/#index) để hiểu được những lợi ích mà chúng mang lại cho việc thiết kế hệ thống. + +Về các nguyên tắc cơ bản của kiến trúc, bạn cần hiểu [API](https://www.wikipedia.org/wiki/API) và [REST](https://www.wikipedia.org/wiki/Representational_state_transfer) là gì, dù chỉ trên lý thuyết. + +## Trình duyệt khối {#block-explorers} + +Nhiều [Trình duyệt khối](/developers/docs/data-and-analytics/block-explorers/) cung cấp các cổng [API](https://www.wikipedia.org/wiki/API) [RESTful](https://www.wikipedia.org/wiki/Representational_state_transfer) giúp các nhà phát triển có được khả năng hiển thị dữ liệu thời gian thực về các khối, giao dịch, người xác thực, tài khoản và các hoạt động trên chuỗi khác. + +Sau đó, các nhà phát triển có thể xử lý và chuyển đổi dữ liệu này để cung cấp cho người dùng của họ những thông tin chi tiết và tương tác độc đáo với [chuỗi khối](/glossary/#blockchain). Ví dụ, [Etherscan](https://etherscan.io) và [Blockscout](https://eth.blockscout.com) cung cấp dữ liệu thực thi và đồng thuận cho mỗi slot 12 giây. + +## The Graph {#the-graph} + +[The Graph](https://thegraph.com/) là một giao thức lập chỉ mục cung cấp một cách dễ dàng để truy vấn dữ liệu chuỗi khối thông qua các API mở được gọi là subgraph. + +Với The Graph, các nhà phát triển có thể hưởng lợi từ: + +- Lập chỉ mục phi tập trung: Cho phép lập chỉ mục dữ liệu chuỗi khối thông qua nhiều trình lập chỉ mục, do đó loại bỏ mọi điểm lỗi đơn lẻ +- Truy vấn GraphQL: Cung cấp giao diện GraphQL mạnh mẽ để truy vấn dữ liệu đã được lập chỉ mục, giúp việc truy xuất dữ liệu trở nên cực kỳ đơn giản +- Tùy chỉnh: Xác định logic của riêng bạn để chuyển đổi và lưu trữ dữ liệu chuỗi khối, đồng thời sử dụng lại các subgraph do các nhà phát triển khác xuất bản trên Mạng The Graph + +Làm theo hướng dẫn [bắt đầu nhanh](https://thegraph.com/docs/en/quick-start/) này để tạo, triển khai và truy vấn một subgraph trong vòng 5 phút. + +## Sự đa dạng của ứng dụng khách {#client-diversity} + +[Sự đa dạng của ứng dụng khách](/developers/docs/nodes-and-clients/client-diversity/) rất quan trọng đối với sức khỏe tổng thể của mạng Ethereum vì nó cung cấp khả năng phục hồi trước các lỗi và khai thác. Hiện có một số bảng thông tin về sự đa dạng của ứng dụng khách bao gồm [clientdiversity.org](https://clientdiversity.org/), [rated.network](https://www.rated.network), [supermajority.info](https://supermajority.info//) và [Ethernodes](https://ethernodes.org/). + +## Dune Analytics {#dune-analytics} + +[Dune Analytics](https://dune.com/) xử lý trước dữ liệu chuỗi khối thành các bảng cơ sở dữ liệu quan hệ (DuneSQL), cho phép người dùng truy vấn dữ liệu chuỗi khối bằng SQL và xây dựng bảng thông tin dựa trên kết quả truy vấn. Dữ liệu trên chuỗi được sắp xếp thành 4 bảng thô: `blocks`, `transactions`, `logs` (sự kiện) và `traces` (lệnh gọi). Các hợp đồng và giao thức phổ biến đã được giải mã và mỗi loại có bộ bảng sự kiện và lệnh gọi riêng. Các bảng sự kiện và lệnh gọi đó được xử lý thêm và sắp xếp thành các bảng trừu tượng theo loại giao thức, ví dụ: dex, cho vay, stablecoin, v.v. + +## SQD {#sqd} + +[SQD](https://sqd.dev/) là một nền tảng dữ liệu phi tập trung, có khả năng mở rộng siêu lớn, được tối ưu hóa để cung cấp quyền truy cập hiệu quả, không cần cấp phép vào các tập dữ liệu lớn. Nền tảng này hiện đang phục vụ dữ liệu lịch sử trên chuỗi, bao gồm nhật ký sự kiện, biên lai giao dịch, dấu vết và chênh lệch trạng thái trên mỗi giao dịch. SQD cung cấp một bộ công cụ mạnh mẽ để tạo các quy trình trích xuất và xử lý dữ liệu tùy chỉnh, đạt tốc độ lập chỉ mục lên tới 150 nghìn khối mỗi giây. + +Để bắt đầu, hãy truy cập [tài liệu tham khảo](https://docs.sqd.dev/) hoặc xem [các ví dụ về EVM](https://github.com/subsquid-labs/squid-evm-examples) về những gì bạn có thể xây dựng với SQD. + +## Mạng SubQuery {#subquery-network} + +[SubQuery](https://subquery.network/) là một công cụ lập chỉ mục dữ liệu hàng đầu, cung cấp cho các nhà phát triển các API nhanh, đáng tin cậy, phi tập trung và tùy chỉnh cho các dự án web3 của họ. SubQuery trao quyền cho các nhà phát triển từ hơn 165 hệ sinh thái (bao gồm cả Ethereum) với dữ liệu được lập chỉ mục phong phú để xây dựng trải nghiệm trực quan và sống động cho người dùng của họ. Mạng SubQuery hỗ trợ các ứng dụng không thể ngăn cản của bạn bằng một mạng cơ sở hạ tầng có khả năng phục hồi và phi tập trung. Sử dụng bộ công cụ dành cho nhà phát triển chuỗi khối của SubQuery để xây dựng các ứng dụng web3 của tương lai mà không tốn thời gian xây dựng một backend tùy chỉnh cho các hoạt động xử lý dữ liệu. + +Để bắt đầu, hãy truy cập [hướng dẫn bắt đầu nhanh với Ethereum](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html) để bắt đầu lập chỉ mục dữ liệu chuỗi khối Ethereum trong vài phút trong môi trường Docker cục bộ để thử nghiệm trước khi hoạt động chính thức trên [dịch vụ được quản lý của SubQuery](https://managedservice.subquery.network/) hoặc trên [mạng phi tập trung của SubQuery](https://app.subquery.network/dashboard). + +## Ngôn ngữ truy vấn EVM {#evm-query-language} + +Ngôn ngữ truy vấn EVM (EQL) là một ngôn ngữ giống SQL được thiết kế để truy vấn các chuỗi EVM (Máy ảo Ethereum). Mục tiêu cuối cùng của EQL là hỗ trợ các truy vấn quan hệ phức tạp trên các thành phần hạng nhất của chuỗi EVM (khối, tài khoản và giao dịch) đồng thời cung cấp cho các nhà phát triển và nhà nghiên cứu một cú pháp tiện dụng để sử dụng hàng ngày. Với EQL, các nhà phát triển có thể tìm nạp dữ liệu chuỗi khối bằng cách sử dụng cú pháp quen thuộc giống SQL và loại bỏ nhu cầu về mã soạn sẵn phức tạp. EQL hỗ trợ các yêu cầu dữ liệu chuỗi khối tiêu chuẩn (ví dụ: truy xuất nonce và số dư của tài khoản trên Ethereum hoặc tìm nạp kích thước khối và dấu thời gian hiện tại) và liên tục bổ sung hỗ trợ cho các yêu cầu và bộ tính năng phức tạp hơn. + +## Đọc thêm {#further-reading} + +- [Khám phá dữ liệu tiền mã hóa I: Các kiến trúc luồng dữ liệu](https://web.archive.org/web/20250125012042/https://research.2077.xyz/exploring-crypto-data-1-data-flow-architectures) +- [Tổng quan về Mạng Graph](https://thegraph.com/docs/en/about/) +- [Sân chơi truy vấn Graph](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current) +- [Các ví dụ về mã API trên EtherScan](https://etherscan.io/apis#contracts) +- [Tài liệu tham khảo API trên Blockscout](https://docs.blockscout.com/devs/apis) +- [Trình khám phá Chuỗi Hải Đăng Beaconcha.in](https://beaconcha.in) +- [Kiến thức cơ bản về Dune](https://docs.dune.com/#dune-basics) +- [Hướng dẫn bắt đầu nhanh với Ethereum của SubQuery](https://academy.subquery.network/indexer/quickstart/quickstart_chains/ethereum-gravatar.html) +- [Tổng quan về Mạng SQD](https://docs.sqd.dev/) +- [Ngôn ngữ truy vấn EVM](https://eql.sh/blog/alpha-release-notes) diff --git a/public/content/translations/vi/developers/docs/data-availability/blockchain-data-storage-strategies/index.md b/public/content/translations/vi/developers/docs/data-availability/blockchain-data-storage-strategies/index.md new file mode 100644 index 00000000000..2721211c392 --- /dev/null +++ b/public/content/translations/vi/developers/docs/data-availability/blockchain-data-storage-strategies/index.md @@ -0,0 +1,118 @@ +--- +title: "Chiến lược lưu trữ dữ liệu chuỗi khối" +description: "Có một số cách để lưu trữ dữ liệu bằng chuỗi khối. Bài viết này sẽ so sánh các chiến lược khác nhau, chi phí và sự đánh đổi của chúng, cũng như các yêu cầu để sử dụng nó một cách an toàn." +lang: vi +--- + +Có nhiều cách để lưu trữ thông tin trực tiếp trên chuỗi khối, hoặc theo cách được bảo mật bởi chuỗi khối: + +- Blob EIP-4844 +- Calldata +- Ngoài chuỗi với các cơ chế L1 +- "Mã" hợp đồng +- Sự kiện +- Lưu trữ máy ảo Ethereum + +Việc lựa chọn phương pháp nào để sử dụng dựa trên một số tiêu chí: + +- Nguồn thông tin. Thông tin trong calldata không thể đến trực tiếp từ chính chuỗi khối. +- Đích đến của thông tin. Calldata chỉ có sẵn trong giao dịch bao gồm nó. Các sự kiện hoàn toàn không thể truy cập trên chuỗi. +- Mức độ phức tạp nào là chấp nhận được? Các máy tính chạy một nút quy mô đầy đủ có thể thực hiện nhiều xử lý hơn một ứng dụng khách nhẹ trong một ứng dụng chạy trên trình duyệt. +- Có cần thiết phải tạo điều kiện truy cập dễ dàng vào thông tin từ mọi nút không? +- Các yêu cầu bảo mật. + +## Các yêu cầu bảo mật {#security-requirements} + +Nhìn chung, bảo mật thông tin bao gồm ba thuộc tính: + +- _Tính bảo mật_, các thực thể không được phép không được phép đọc thông tin. Điều này quan trọng trong nhiều trường hợp, nhưng không phải ở đây. _Không có bí mật nào trên chuỗi khối_. Các chuỗi khối hoạt động vì bất kỳ ai cũng có thể xác minh các chuyển đổi trạng thái, vì vậy không thể sử dụng chúng để lưu trữ bí mật trực tiếp. Có nhiều cách để lưu trữ thông tin bí mật trên chuỗi khối, nhưng tất cả chúng đều dựa vào một số thành phần ngoài chuỗi để lưu trữ ít nhất một khóa. + +- _Tính toàn vẹn_, thông tin là chính xác, nó không thể bị thay đổi bởi các thực thể không được ủy quyền, hoặc theo những cách không được ủy quyền (ví dụ: chuyển [token ERC-20](https://eips.ethereum.org/EIPS/eip-20#events) mà không có sự kiện `Transfer`). Trên chuỗi khối, mọi nút đều xác minh mọi thay đổi trạng thái, điều này đảm bảo tính toàn vẹn. + +- _Tính sẵn có_, thông tin có sẵn cho bất kỳ thực thể được ủy quyền nào. Trên chuỗi khối, điều này thường đạt được bằng cách làm cho thông tin có sẵn trên mọi [nút đầy đủ](https://ethereum.org/developers/docs/nodes-and-clients#full-node). + +Các giải pháp khác nhau ở đây đều có tính toàn vẹn tuyệt vời, vì các hàm băm được đăng trên L1. Tuy nhiên, chúng có các đảm bảo về tính sẵn có khác nhau. + +## Điều kiện tiên quyết {#prerequisites} + +Bạn nên có hiểu biết tốt về [các nguyên tắc cơ bản của chuỗi khối](/developers/docs/intro-to-ethereum/). Trang này cũng giả định người đọc đã quen thuộc với [khối](/developers/docs/blocks/), [giao dịch](/developers/docs/transactions/) và các chủ đề liên quan khác. + +## Blob EIP-4844 {#eip-4844-blobs} + +Bắt đầu với [bản nâng cấp Dencun](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md), chuỗi khối Ethereum bao gồm [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844), bổ sung các blob dữ liệu vào Ethereum với thời gian tồn tại giới hạn (ban đầu khoảng [18 ngày](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration)). Chúng được định giá riêng biệt với [gas thực thi](/developers/docs/gas), mặc dù sử dụng một cơ chế tương tự. Chúng là một cách rẻ tiền để đăng dữ liệu tạm thời. + +Trường hợp sử dụng chính cho các blob EIP-4844 là để các rollup xuất bản các giao dịch của chúng. [Gộp giao dịch lạc quan](/developers/docs/scaling/optimistic-rollups) cần xuất bản các giao dịch trên chuỗi khối của họ. Những giao dịch đó phải có sẵn cho bất kỳ ai trong [thời gian thử thách](https://docs.optimism.io/connect/resources/glossary#challenge-period) để cho phép [người xác thực](https://docs.optimism.io/connect/resources/glossary#validator) sửa lỗi nếu [trình sắp xếp thứ tự](https://docs.optimism.io/connect/resources/glossary#sequencer) của rollup đăng một gốc trạng thái không chính xác. + +Tuy nhiên, một khi thời gian thử thách đã qua và gốc trạng thái được hoàn tất, mục đích còn lại để biết các giao dịch này là để sao chép trạng thái hiện tại của chuỗi. Trạng thái này cũng có sẵn từ các nút chuỗi, với yêu cầu xử lý ít hơn nhiều. Vì vậy, thông tin giao dịch vẫn nên được lưu giữ ở một vài nơi, chẳng hạn như [trình khám phá khối](/developers/docs/data-and-analytics/block-explorers), nhưng không cần phải trả tiền cho mức độ chống kiểm duyệt mà Ethereum cung cấp. + +[Rollup không kiến thức](/developers/docs/scaling/zk-rollups/#data-availability) cũng đăng dữ liệu giao dịch của họ để cho phép các nút khác sao chép trạng thái hiện có và xác minh bằng chứng hợp lệ, nhưng một lần nữa đó là một yêu cầu ngắn hạn. + +Tại thời điểm viết bài, việc đăng trên EIP-4844 tốn một wei (10-18 ETH) mỗi byte, một con số không đáng kể so với [21.000 gas thực thi mà bất kỳ giao dịch nào, bao gồm cả giao dịch đăng blob, đều tốn](https://eth.blockscout.com/tx/0xf6cfaf0431c73dd1d96369a5e6707d64f463ccf477a4131265397f1d81466929?tab=index). Bạn có thể xem giá EIP-4844 hiện tại trên [blobscan.com](https://blobscan.com/blocks). + +Đây là các địa chỉ để xem các blob được đăng bởi một số rollup nổi tiếng. + +| Rollup | Địa chỉ hộp thư | +| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | +| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://blobscan.com/address/0xFF00000000000000000000000000000000000010) | +| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://blobscan.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) | +| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://blobscan.com/address/0xFF00000000000000000000000000000000008453) | + +## Calldata {#calldata} + +Calldata đề cập đến các byte được gửi như một phần của giao dịch. Nó được lưu trữ như một phần của bản ghi vĩnh viễn của chuỗi khối trong khối bao gồm giao dịch đó. + +Đây là phương pháp rẻ nhất để đưa dữ liệu vĩnh viễn vào chuỗi khối. Chi phí cho mỗi byte là 4 gas thực thi (nếu byte là 0) hoặc 16 gas (bất kỳ giá trị nào khác). Nếu dữ liệu được nén, đây là một phương pháp tiêu chuẩn, thì mọi giá trị byte đều có khả năng như nhau, vì vậy chi phí trung bình là khoảng 15,95 gas mỗi byte. + +Tại thời điểm viết bài, giá là 12 gwei/gas và 2300 $/ETH, có nghĩa là chi phí khoảng 45 xu cho mỗi kilobyte. Bởi vì đây là phương pháp rẻ nhất trước EIP-4844, đây là phương pháp mà các rollup đã sử dụng để lưu trữ thông tin giao dịch, thông tin này cần có sẵn cho [các thử thách lỗi](https://docs.optimism.io/stack/protocol/overview#fault-proofs), nhưng không cần phải truy cập trực tiếp trên chuỗi. + +Đây là các địa chỉ để xem các giao dịch được đăng bởi một số rollup nổi tiếng. + +| Rollup | Địa chỉ hộp thư | +| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | +| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000000010) | +| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://eth.blockscout.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) | +| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000008453) | + +## Ngoài chuỗi với cơ chế L1 {#offchain-with-l1-mechs} + +Tùy thuộc vào sự đánh đổi về bảo mật của bạn, có thể chấp nhận đặt thông tin ở nơi khác và sử dụng một cơ chế đảm bảo dữ liệu có sẵn khi cần. Có hai yêu cầu để điều này hoạt động: + +1. Đăng một [hàm băm](https://en.wikipedia.org/wiki/Cryptographic_hash_function) của dữ liệu trên chuỗi khối, được gọi là _cam kết đầu vào_. Đây có thể là một từ 32 byte duy nhất, vì vậy nó không tốn kém. Miễn là cam kết đầu vào có sẵn, tính toàn vẹn được đảm bảo vì không khả thi để tìm bất kỳ dữ liệu nào khác sẽ băm ra cùng một giá trị. Vì vậy, nếu dữ liệu không chính xác được cung cấp, nó có thể được phát hiện. + +2. Có một cơ chế đảm bảo tính sẵn có. Ví dụ: trong [Redstone](https://redstone.xyz/docs/what-is-redstone), bất kỳ nút nào cũng có thể gửi một thử thách về tính sẵn có. Nếu trình sắp xếp thứ tự không phản hồi trên chuỗi trước thời hạn, cam kết đầu vào sẽ bị hủy, vì vậy thông tin được coi là chưa bao giờ được đăng. + +Điều này có thể chấp nhận được đối với một gộp giao dịch lạc quan vì chúng tôi đã dựa vào việc có ít nhất một người xác minh trung thực cho gốc trạng thái. Một người xác minh trung thực như vậy cũng sẽ đảm bảo rằng nó có dữ liệu để xử lý các khối và đưa ra một thử thách về tính sẵn có nếu thông tin không có sẵn ngoài chuỗi. Loại gộp giao dịch lạc quan này được gọi là [plasma](/developers/docs/scaling/plasma/). + +## Mã hợp đồng {#contract-code} + +Thông tin chỉ cần được viết một lần, không bao giờ bị ghi đè và cần có sẵn trên chuỗi có thể được lưu trữ dưới dạng mã hợp đồng. Điều này có nghĩa là chúng tôi tạo một "hợp đồng thông minh" với dữ liệu và sau đó sử dụng [`EXTCODECOPY`](https://www.evm.codes/#3c?fork=shanghai) để đọc thông tin. Ưu điểm là sao chép mã tương đối rẻ. + +Ngoài chi phí mở rộng bộ nhớ, `EXTCODECOPY` tốn 2600 gas cho lần truy cập đầu tiên vào một hợp đồng (khi nó ở trạng thái "lạnh") và 100 gas cho các lần sao chép tiếp theo từ cùng một hợp đồng cộng với 3 gas cho mỗi từ 32 byte. So với calldata, có giá 15,95 mỗi byte, thì cách này rẻ hơn bắt đầu từ khoảng 200 byte. Dựa trên [công thức tính chi phí mở rộng bộ nhớ](https://www.evm.codes/about#memoryexpansion), miễn là bạn không cần nhiều hơn 4MB bộ nhớ, chi phí mở rộng bộ nhớ sẽ nhỏ hơn chi phí thêm calldata. + +Tất nhiên, đây chỉ là chi phí để _đọc_ dữ liệu. Để tạo hợp đồng tốn khoảng 32.000 gas + 200 gas/byte. Phương pháp này chỉ kinh tế khi cùng một thông tin cần được đọc nhiều lần trong các giao dịch khác nhau. + +Mã hợp đồng có thể vô nghĩa, miễn là nó không bắt đầu bằng `0xEF`. Các hợp đồng bắt đầu bằng `0xEF` được hiểu là [định dạng đối tượng ethereum](https://notes.ethereum.org/@ipsilon/evm-object-format-overview), có các yêu cầu nghiêm ngặt hơn nhiều. + +## Sự kiện {#events} + +[Các sự kiện](https://docs.alchemy.com/docs/solidity-events) được phát ra bởi các hợp đồng thông minh và được đọc bởi phần mềm ngoài chuỗi. +Ưu điểm của chúng là mã ngoài chuỗi có thể lắng nghe các sự kiện. Chi phí là [gas](https://www.evm.codes/#a0?fork=cancun), 375 cộng với 8 gas cho mỗi byte dữ liệu. Với 12 gwei/gas và 2300 $/ETH, điều này tương đương với một xu cộng với 22 xu cho mỗi kilobyte. + +## Lưu trữ {#storage} + +Các hợp đồng thông minh có quyền truy cập vào [lưu trữ bền vững](https://docs.alchemy.com/docs/smart-contract-storage-layout#what-is-storage-memory). Tuy nhiên, nó rất tốn kém. Việc ghi một từ 32 byte vào một khe lưu trữ trống trước đó có thể [tốn 22.100 gas](https://www.evm.codes/#55?fork=cancun). Với 12 gwei/gas và 2300 $/ETH, con số này là khoảng 61 xu cho mỗi hoạt động ghi, hoặc 19,5 đô la cho mỗi kilobyte. + +Đây là hình thức lưu trữ đắt nhất trong Ethereum. + +## Tóm tắt {#summary} + +Bảng này tóm tắt các tùy chọn khác nhau, ưu và nhược điểm của chúng. + +| Loại lưu trữ | Nguồn dữ liệu | Đảm bảo tính sẵn có | Tính sẵn có trên chuỗi | Các giới hạn bổ sung | +| ----------------------------- | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------- | -------------------------------------------------------------------- | +| Blob EIP-4844 | Ngoài chuỗi | Ethereum đảm bảo trong [~18 ngày](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration) | Chỉ có hàm băm | | +| Calldata | Ngoài chuỗi | Ethereum đảm bảo mãi mãi (một phần của chuỗi khối) | Chỉ có sẵn nếu được ghi vào hợp đồng và tại giao dịch đó | | +| Ngoài chuỗi với các cơ chế L1 | Ngoài chuỗi | Đảm bảo "một người xác minh trung thực" trong thời gian thử thách | Chỉ hàm băm | Được đảm bảo bởi cơ chế thử thách, chỉ trong thời gian thử thách | +| Mã hợp đồng | Trên chuỗi hoặc ngoài chuỗi | Ethereum đảm bảo mãi mãi (một phần của chuỗi khối) | Có | Được ghi vào một địa chỉ "ngẫu nhiên", không thể bắt đầu bằng `0xEF` | +| Sự kiện | Trên chuỗi | Ethereum đảm bảo mãi mãi (một phần của chuỗi khối) | Không | | +| Lưu trữ | Trên chuỗi | Ethereum đảm bảo mãi mãi (một phần của chuỗi khối và trạng thái hiện tại cho đến khi bị ghi đè) | Có | | diff --git a/public/content/translations/vi/developers/docs/data-availability/index.md b/public/content/translations/vi/developers/docs/data-availability/index.md new file mode 100644 index 00000000000..abed56d62b5 --- /dev/null +++ b/public/content/translations/vi/developers/docs/data-availability/index.md @@ -0,0 +1,84 @@ +--- +title: "Tính khả dụng dữ liệu" +description: "Tổng quan về các vấn đề và giải pháp liên quan đến tính sẵn sàng của dữ liệu trong Ethereum" +lang: vi +--- + +"Đừng tin tưởng, hãy xác minh" là một câu châm ngôn phổ biến trong Ethereum. Ý tưởng là nút của bạn có thể xác minh một cách độc lập rằng thông tin nó nhận được là chính xác bằng cách thực hiện tất cả các giao dịch trong các khối mà nó nhận được từ các máy ngang hàng để đảm bảo rằng các thay đổi được đề xuất khớp chính xác với các thay đổi được tính toán độc lập bởi nút. Điều này có nghĩa là các nút không cần phải tin rằng những người gửi khối là trung thực. Điều này là không thể nếu dữ liệu bị thiếu. + +**Tính sẵn sàng của dữ liệu** đề cập đến sự tự tin mà người dùng có thể có rằng dữ liệu cần thiết để xác minh một khối thực sự có sẵn cho tất cả những người tham gia mạng. Đối với các nút đầy đủ trên Lớp 1 của Ethereum, điều này tương đối đơn giản; nút đầy đủ tải xuống một bản sao của tất cả dữ liệu trong mỗi khối - dữ liệu _phải_ có sẵn để có thể tải xuống. Một khối có dữ liệu bị thiếu sẽ bị loại bỏ thay vì được thêm vào chuỗi khối. Đây là "tính sẵn sàng của dữ liệu trên chuỗi" và là một tính năng của các chuỗi khối nguyên khối. Các nút đầy đủ không thể bị lừa để chấp nhận các giao dịch không hợp lệ vì chúng tự tải xuống và thực hiện mọi giao dịch. Tuy nhiên, đối với các chuỗi khối mô-đun, các rollup Lớp 2 và các ứng dụng khách nhẹ, bối cảnh về tính sẵn sàng của dữ liệu phức tạp hơn, đòi hỏi một số quy trình xác minh phức tạp hơn. + +## Điều kiện tiên quyết {#prerequisites} + +Bạn nên có kiến thức tốt về [các nguyên tắc cơ bản của chuỗi khối](/developers/docs/intro-to-ethereum/), đặc biệt là [các cơ chế đồng thuận](/developers/docs/consensus-mechanisms/). Trang này cũng giả định rằng người đọc đã quen thuộc với [khối](/developers/docs/blocks/), [giao dịch](/developers/docs/transactions/), [nút](/developers/docs/nodes-and-clients/), [các giải pháp mở rộng](/developers/docs/scaling/) và các chủ đề liên quan khác. + +## Vấn đề về tính sẵn sàng của dữ liệu {#the-data-availability-problem} + +Vấn đề về tính sẵn sàng của dữ liệu là nhu cầu chứng minh cho toàn bộ mạng rằng dạng tóm tắt của một số dữ liệu giao dịch đang được thêm vào chuỗi khối thực sự đại diện cho một tập hợp các giao dịch hợp lệ, nhưng làm như vậy mà không yêu cầu tất cả các nút phải tải xuống tất cả dữ liệu. Dữ liệu giao dịch đầy đủ là cần thiết để xác minh các khối một cách độc lập, nhưng việc yêu cầu tất cả các nút tải xuống tất cả dữ liệu giao dịch là một rào cản đối với việc mở rộng. Các giải pháp cho vấn đề về tính sẵn sàng của dữ liệu nhằm cung cấp đủ sự đảm bảo rằng dữ liệu giao dịch đầy đủ đã được cung cấp để xác minh cho những người tham gia mạng không tự tải xuống và lưu trữ dữ liệu. + +[Các nút nhẹ](/developers/docs/nodes-and-clients/light-clients) và [các rollup Lớp 2](/developers/docs/scaling) là những ví dụ quan trọng về những người tham gia mạng yêu cầu sự đảm bảo mạnh mẽ về tính sẵn sàng của dữ liệu nhưng không thể tự tải xuống và xử lý dữ liệu giao dịch. Việc tránh tải xuống dữ liệu giao dịch là điều làm cho các nút nhẹ trở nên nhẹ và cho phép các rollup trở thành giải pháp mở rộng hiệu quả. + +Tính sẵn sàng của dữ liệu cũng là một mối quan tâm quan trọng đối với các ứng dụng khách Ethereum ["không trạng thái"](/roadmap/statelessness) trong tương lai không cần tải xuống và lưu trữ dữ liệu trạng thái để xác minh các khối. Các ứng dụng khách không trạng thái vẫn cần chắc chắn rằng dữ liệu có sẵn ở _đâu đó_ và đã được xử lý chính xác. + +## Các giải pháp về tính sẵn sàng của dữ liệu {#data-availability-solutions} + +### Lấy mẫu tính sẵn sàng của dữ liệu (DAS) {#data-availability-sampling} + +Lấy mẫu tính sẵn sàng của dữ liệu (DAS) là một cách để mạng kiểm tra xem dữ liệu có sẵn hay không mà không gây quá nhiều áp lực cho bất kỳ nút riêng lẻ nào. Mỗi nút (bao gồm cả các nút không tham gia staking) tải xuống một tập hợp con nhỏ, được chọn ngẫu nhiên của tổng dữ liệu. Việc tải xuống thành công các mẫu xác nhận với độ tin cậy cao rằng tất cả dữ liệu đều có sẵn. Điều này dựa trên mã hóa xóa dữ liệu, giúp mở rộng một bộ dữ liệu nhất định với thông tin dự phòng (cách thực hiện điều này là điều chỉnh một hàm được gọi là _đa thức_ trên dữ liệu và đánh giá đa thức đó tại các điểm bổ sung). Điều này cho phép khôi phục dữ liệu gốc từ dữ liệu dự phòng khi cần thiết. Hệ quả của việc tạo dữ liệu này là nếu _bất kỳ_ dữ liệu gốc nào không có sẵn, _một nửa_ dữ liệu mở rộng sẽ bị thiếu! Lượng mẫu dữ liệu được mỗi nút tải xuống có thể được điều chỉnh để _cực kỳ_ có khả năng ít nhất một trong các mảnh dữ liệu được mỗi ứng dụng khách lấy mẫu sẽ bị thiếu _nếu_ thực sự có ít hơn một nửa dữ liệu. + +DAS sẽ được sử dụng để đảm bảo các nhà khai thác rollup cung cấp dữ liệu giao dịch của họ sau khi [Full Danksharding](/roadmap/danksharding/#what-is-danksharding) được triển khai. Các nút Ethereum sẽ lấy mẫu ngẫu nhiên dữ liệu giao dịch được cung cấp trong các blob bằng cách sử dụng lược đồ dự phòng đã giải thích ở trên để đảm bảo rằng tất cả dữ liệu đều tồn tại. Kỹ thuật tương tự cũng có thể được sử dụng để đảm bảo các nhà sản xuất khối cung cấp tất cả dữ liệu của họ cho các ứng dụng khách nhẹ bảo mật. Tương tự, trong [tách biệt người đề xuất-người xây dựng](/roadmap/pbs), chỉ người xây dựng khối mới được yêu cầu xử lý toàn bộ khối - các trình xác thực khác sẽ xác minh bằng cách lấy mẫu tính sẵn sàng của dữ liệu. + +### Các ủy ban về tính sẵn sàng của dữ liệu {#data-availability-committees} + +Các Ủy ban về tính sẵn sàng của dữ liệu (DAC) là các bên đáng tin cậy cung cấp hoặc chứng thực tính sẵn sàng của dữ liệu. Các DAC có thể được sử dụng thay cho, [hoặc kết hợp với](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS) DAS. Các đảm bảo bảo mật đi kèm với các ủy ban phụ thuộc vào thiết lập cụ thể. Ví dụ: Ethereum sử dụng các tập hợp con được lấy mẫu ngẫu nhiên của các trình xác thực để chứng thực tính sẵn sàng của dữ liệu cho các nút nhẹ. + +DAC cũng được một số validium sử dụng. DAC là một tập hợp các nút đáng tin cậy lưu trữ các bản sao dữ liệu ngoài chuỗi. DAC được yêu cầu cung cấp dữ liệu trong trường hợp có tranh chấp. Các thành viên của DAC cũng công bố các chứng thực trên chuỗi để chứng minh rằng dữ liệu đã nói thực sự có sẵn. Một số validium thay thế DAC bằng hệ thống trình xác thực bằng chứng cổ phần (PoS). Ở đây, bất kỳ ai cũng có thể trở thành trình xác thực và lưu trữ dữ liệu ngoài chuỗi. Tuy nhiên, họ phải cung cấp một “khoản ký quỹ”, được gửi vào một hợp đồng thông minh. Trong trường hợp có hành vi độc hại, chẳng hạn như trình xác thực giữ lại dữ liệu, khoản ký quỹ có thể bị phạt. Các ủy ban về tính sẵn sàng của dữ liệu bằng chứng cổ phần an toàn hơn đáng kể so với các DAC thông thường vì chúng trực tiếp khuyến khích hành vi trung thực. + +## Tính sẵn sàng của dữ liệu và các nút nhẹ {#data-availability-and-light-nodes} + +[Các nút nhẹ](/developers/docs/nodes-and-clients/light-clients) cần xác thực tính chính xác của các tiêu đề khối mà chúng nhận được mà không cần tải xuống dữ liệu khối. Cái giá của sự nhẹ nhàng này là không có khả năng xác minh độc lập các tiêu đề khối bằng cách thực hiện lại các giao dịch cục bộ theo cách mà các nút đầy đủ thực hiện. + +Các nút nhẹ của Ethereum tin tưởng các bộ ngẫu nhiên gồm 512 trình xác thực đã được chỉ định cho một _ủy ban đồng bộ hóa_. Ủy ban đồng bộ hóa hoạt động như một DAC báo hiệu cho các ứng dụng khách nhẹ rằng dữ liệu trong tiêu đề là chính xác bằng cách sử dụng chữ ký mật mã. Hàng ngày, ủy ban đồng bộ hóa sẽ làm mới. Mỗi tiêu đề khối cảnh báo các nút nhẹ về việc trình xác thực nào sẽ ký vào khối _tiếp theo_, vì vậy chúng không thể bị lừa để tin tưởng một nhóm độc hại giả vờ là ủy ban đồng bộ hóa thực sự. + +Tuy nhiên, điều gì sẽ xảy ra nếu một kẻ tấn công bằng cách nào đó _thực sự_ quản lý để chuyển một tiêu đề khối độc hại cho các ứng dụng khách nhẹ và thuyết phục họ rằng nó đã được ký bởi một ủy ban đồng bộ hóa trung thực? Trong trường hợp đó, kẻ tấn công có thể bao gồm các giao dịch không hợp lệ và ứng dụng khách nhẹ sẽ chấp nhận chúng một cách mù quáng, vì chúng không kiểm tra độc lập tất cả các thay đổi trạng thái được tóm tắt trong tiêu đề khối. Để bảo vệ chống lại điều này, ứng dụng khách nhẹ có thể sử dụng các bằng chứng gian lận. + +Cách các bằng chứng gian lận này hoạt động là một nút đầy đủ, khi thấy một quá trình chuyển đổi trạng thái không hợp lệ được lan truyền trên mạng, có thể nhanh chóng tạo ra một mẩu dữ liệu nhỏ chứng minh rằng một quá trình chuyển đổi trạng thái được đề xuất không thể phát sinh từ một tập hợp giao dịch nhất định và phát sóng dữ liệu đó cho các máy ngang hàng. Các nút nhẹ có thể nhận các bằng chứng gian lận đó và sử dụng chúng để loại bỏ các tiêu đề khối xấu, đảm bảo chúng ở trên cùng một chuỗi trung thực với các nút đầy đủ. + +Điều này dựa vào việc các nút đầy đủ có quyền truy cập vào dữ liệu giao dịch đầy đủ. Một kẻ tấn công phát sóng một tiêu đề khối xấu và cũng không cung cấp dữ liệu giao dịch sẽ có thể ngăn các nút đầy đủ tạo ra các bằng chứng gian lận. Các nút đầy đủ có thể có thể báo hiệu một cảnh báo về một khối xấu, nhưng chúng không thể sao lưu cảnh báo của mình bằng bằng chứng, vì dữ liệu không được cung cấp để tạo ra bằng chứng từ đó! + +Giải pháp cho vấn đề về tính sẵn sàng của dữ liệu này là DAS. Các nút nhẹ tải xuống các phần ngẫu nhiên rất nhỏ của dữ liệu trạng thái đầy đủ và sử dụng các mẫu để xác minh rằng bộ dữ liệu đầy đủ có sẵn. Xác suất thực tế của việc giả định sai về tính sẵn sàng của dữ liệu đầy đủ sau khi tải xuống N phần ngẫu nhiên có thể được tính toán ([đối với 100 phần, xác suất là 10^-30](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html), tức là cực kỳ khó xảy ra). + +Ngay cả trong kịch bản này, các cuộc tấn công chỉ giữ lại một vài byte cũng có thể không bị các ứng dụng khách đưa ra yêu cầu dữ liệu ngẫu nhiên phát hiện. Mã hóa xóa khắc phục điều này bằng cách tái tạo lại các mẩu dữ liệu bị thiếu nhỏ có thể được sử dụng để kiểm tra các thay đổi trạng thái được đề xuất. Sau đó, một bằng chứng gian lận có thể được xây dựng bằng cách sử dụng dữ liệu được tái tạo, ngăn chặn các nút nhẹ chấp nhận các tiêu đề xấu. + +**Lưu ý:** DAS và bằng chứng gian lận vẫn chưa được triển khai cho các ứng dụng khách nhẹ Ethereum bằng chứng cổ phần, nhưng chúng có trong lộ trình, rất có thể sẽ ở dạng bằng chứng dựa trên ZK-SNARK. Các ứng dụng khách nhẹ ngày nay dựa vào một dạng DAC: chúng xác minh danh tính của ủy ban đồng bộ hóa và sau đó tin tưởng vào các tiêu đề khối đã ký mà chúng nhận được. + +## Tính sẵn sàng của dữ liệu và các rollup Lớp 2 {#data-availability-and-layer-2-rollups} + +[Các giải pháp mở rộng Lớp 2](/layer-2/), chẳng hạn như [rollup](/glossary/#rollups), giảm chi phí giao dịch và tăng thông lượng của Ethereum bằng cách xử lý các giao dịch ngoài chuỗi. Các giao dịch rollup được nén và đăng lên Ethereum theo lô. Các lô đại diện cho hàng nghìn giao dịch ngoài chuỗi riêng lẻ trong một giao dịch duy nhất trên Ethereum. Điều này làm giảm tắc nghẽn trên lớp cơ sở và giảm phí cho người dùng. + +Tuy nhiên, chỉ có thể tin tưởng các giao dịch 'tóm tắt' được đăng lên Ethereum nếu sự thay đổi trạng thái được đề xuất có thể được xác minh và xác nhận một cách độc lập là kết quả của việc áp dụng tất cả các giao dịch ngoài chuỗi riêng lẻ. Nếu các nhà khai thác rollup không cung cấp dữ liệu giao dịch để xác minh này, thì họ có thể gửi dữ liệu không chính xác đến Ethereum. + +[Gộp giao dịch lạc quan](/developers/docs/scaling/optimistic-rollups/) đăng dữ liệu giao dịch nén lên Ethereum và đợi một khoảng thời gian (thường là 7 ngày) để cho phép các trình xác minh độc lập kiểm tra dữ liệu. Nếu bất kỳ ai xác định được vấn đề, họ có thể tạo ra một bằng chứng gian lận và sử dụng nó để thách thức rollup. Điều này sẽ khiến chuỗi quay trở lại và bỏ qua khối không hợp lệ. Điều này chỉ có thể thực hiện được nếu dữ liệu có sẵn. Hiện tại, có hai cách mà các gộp giao dịch lạc quan đăng dữ liệu giao dịch lên L1. Một số rollup cung cấp dữ liệu vĩnh viễn dưới dạng `CALLDATA`, tồn tại vĩnh viễn trên chuỗi. Với việc triển khai EIP-4844, một số rollup thay vào đó đăng dữ liệu giao dịch của họ vào bộ lưu trữ blob rẻ hơn. Đây không phải là bộ lưu trữ vĩnh viễn. Các trình xác minh độc lập phải truy vấn các blob và đưa ra các thách thức của họ trong vòng ~18 ngày trước khi dữ liệu bị xóa khỏi lớp 1 của Ethereum. Tính sẵn sàng của dữ liệu chỉ được đảm bảo bởi giao thức Ethereum trong khoảng thời gian cố định ngắn đó. Sau đó, nó trở thành trách nhiệm của các thực thể khác trong hệ sinh thái Ethereum. Bất kỳ nút nào cũng có thể xác minh tính sẵn sàng của dữ liệu bằng cách sử dụng DAS, tức là bằng cách tải xuống các mẫu dữ liệu blob nhỏ, ngẫu nhiên. + +[Các rollup không kiến thức (ZK)](/developers/docs/scaling/zk-rollups) không cần đăng dữ liệu giao dịch vì [các bằng chứng hợp lệ không kiến thức](/glossary/#zk-proof) đảm bảo tính chính xác của các quá trình chuyển đổi trạng thái. Tuy nhiên, tính sẵn sàng của dữ liệu vẫn là một vấn đề vì chúng ta không thể đảm bảo chức năng của ZK-rollup (hoặc tương tác với nó) mà không có quyền truy cập vào dữ liệu trạng thái của nó. Ví dụ: người dùng không thể biết số dư của mình nếu một nhà khai thác giữ lại thông tin chi tiết về trạng thái của rollup. Ngoài ra, họ không thể thực hiện cập nhật trạng thái bằng cách sử dụng thông tin có trong một khối mới được thêm vào. + +## Tính sẵn sàng của dữ liệu so với khả năng truy xuất dữ liệu {#data-availability-vs-data-retrievability} + +Tính sẵn sàng của dữ liệu khác với khả năng truy xuất dữ liệu. Tính sẵn sàng của dữ liệu là sự đảm bảo rằng các nút đầy đủ đã có thể truy cập và xác minh toàn bộ tập hợp các giao dịch liên quan đến một khối cụ thể. Điều đó không nhất thiết có nghĩa là dữ liệu có thể truy cập được mãi mãi. + +Khả năng truy xuất dữ liệu là khả năng các nút truy xuất _thông tin lịch sử_ từ chuỗi khối. Dữ liệu lịch sử này không cần thiết để xác minh các khối mới, nó chỉ được yêu cầu để đồng bộ hóa các nút đầy đủ từ khối khởi nguyên hoặc phục vụ các yêu cầu lịch sử cụ thể. + +Giao thức cốt lõi của Ethereum chủ yếu quan tâm đến tính sẵn sàng của dữ liệu, không phải khả năng truy xuất dữ liệu. Khả năng truy xuất dữ liệu có thể được cung cấp bởi một số lượng nhỏ các nút lưu trữ do bên thứ ba điều hành, hoặc nó có thể được phân phối trên toàn mạng bằng cách sử dụng lưu trữ tệp phi tập trung như [Mạng Portal](https://www.ethportal.net/). + +## Đọc thêm {#further-reading} + +- [Tính sẵn sàng của dữ liệu là cái quái gì?](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f) +- [Tính sẵn sàng của dữ liệu là gì?](https://coinmarketcap.com/academy/article/what-is-data-availability) +- [Giới thiệu cơ bản về kiểm tra tính sẵn sàng của dữ liệu](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) +- [Giải thích về đề xuất phân mảnh + DAS](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) +- [Lưu ý về tính sẵn sàng của dữ liệu và mã hóa xóa](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them) +- [Các ủy ban về tính sẵn sàng của dữ liệu.](https://medium.com/starkware/data-availability-e5564c416424) +- [Các ủy ban về tính sẵn sàng của dữ liệu bằng chứng cổ phần.](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) +- [Các giải pháp cho vấn đề truy xuất dữ liệu](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding) +- [Tính sẵn sàng của dữ liệu hoặc: Các rollup đã học cách ngừng lo lắng và yêu Ethereum như thế nào](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https://research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum) +- [EIP-7623: Tăng chi phí Calldata](https://web.archive.org/web/20250515194659/https://research.2077.xyz/eip-7623-increase-calldata-cost) diff --git a/public/content/translations/vi/developers/docs/data-structures-and-encoding/index.md b/public/content/translations/vi/developers/docs/data-structures-and-encoding/index.md new file mode 100644 index 00000000000..f60aba7b6f3 --- /dev/null +++ b/public/content/translations/vi/developers/docs/data-structures-and-encoding/index.md @@ -0,0 +1,32 @@ +--- +title: "Cấu trúc dữ liệu và mã hoá" +description: "Tổng quan về các cấu trúc dữ liệu cơ bản của Ethereum." +lang: vi +sidebarDepth: 2 +--- + +Ethereum tạo, lưu trữ và chuyển một lượng lớn dữ liệu. Dữ liệu này phải được định dạng theo những cách được tiêu chuẩn hóa và tiết kiệm bộ nhớ để cho phép bất kỳ ai [chạy một nút](/run-a-node/) trên phần cứng cấp tiêu dùng tương đối khiêm tốn. Để đạt được điều này, một số cấu trúc dữ liệu cụ thể được sử dụng trên ngăn xếp Ethereum. + +## Điều kiện tiên quyết {#prerequisites} + +Bạn nên hiểu các nguyên tắc cơ bản của Ethereum và [phần mềm máy khách](/developers/docs/nodes-and-clients/). Nên làm quen với lớp mạng và [Giấy trắng Ethereum](/whitepaper/). + +## Các cấu trúc dữ liệu {#data-structures} + +### Patricia merkle tries {#patricia-merkle-tries} + +Patricia Merkle Tries là các cấu trúc mã hóa các cặp khóa-giá trị thành một cây trie mang tính tất định và được xác thực bằng mật mã. Những cấu trúc này được sử dụng rộng rãi trên lớp thực thi của Ethereum. + +[Tìm hiểu thêm về Patricia Merkle Tries](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) + +### Tiền tố Độ dài Đệ quy {#recursive-length-prefix} + +Tiền tố độ dài đệ quy (RLP) là một phương pháp tuần tự hóa được sử dụng rộng rãi trên lớp thực thi của Ethereum. + +[Tìm hiểu thêm về RLP](/developers/docs/data-structures-and-encoding/rlp) + +### Tuần tự hóa Đơn giản {#simple-serialize} + +Tuần tự hóa đơn giản (SSZ) là định dạng tuần tự hóa chủ đạo trên lớp đồng thuận của Ethereum vì khả năng tương thích của nó với việc merkle hóa. + +[Tìm hiểu thêm về SSZ](/developers/docs/data-structures-and-encoding/ssz) diff --git a/public/content/translations/vi/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/vi/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md new file mode 100644 index 00000000000..0176837a9bb --- /dev/null +++ b/public/content/translations/vi/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -0,0 +1,266 @@ +--- +title: "Cây Merkle Patricia" +description: "Giới thiệu về Cây Merkle Patricia." +lang: vi +sidebarDepth: 2 +--- + +Trạng thái của Ethereum (toàn bộ các tài khoản, số dư và hợp đồng thông minh), được mã hóa thành một phiên bản đặc biệt của cấu trúc dữ liệu thường được biết đến trong khoa học máy tính với tên gọi là Cây Merkle. Cấu trúc này hữu ích cho nhiều ứng dụng trong mật mã học vì nó tạo ra một mối quan hệ có thể xác minh được giữa tất cả các phần dữ liệu riêng lẻ bị vướng vào trong cây, tạo ra một giá trị **gốc** duy nhất có thể được sử dụng để chứng minh mọi thứ về dữ liệu. + +Cấu trúc dữ liệu của Ethereum là một 'Cây Merkle-Patricia đã sửa đổi', được đặt tên như vậy vì nó vay mượn một số tính năng của PATRICIA (Thuật toán thực tế để truy xuất thông tin được mã hóa bằng chữ và số) và vì nó được thiết kế để truy xuất dữ liệu hiệu quả các mục bao gồm trạng thái Ethereum. + +Một cây Merkle-Patricia mang tính xác định và có thể xác minh bằng phương pháp mật mã: Cách duy nhất để tạo ra một gốc trạng thái là tính toán nó từ mỗi phần riêng lẻ của trạng thái, và hai trạng thái giống hệt nhau có thể dễ dàng được chứng minh bằng cách so sánh băm gốc và các băm dẫn đến nó (_một bằng chứng Merkle_). Ngược lại, không có cách nào để tạo ra hai trạng thái khác nhau với cùng một băm gốc và mọi nỗ lực sửa đổi trạng thái bằng các giá trị khác nhau sẽ dẫn đến một băm gốc trạng thái khác. Về mặt lý thuyết, cấu trúc này cung cấp 'chén thánh' về hiệu quả `O(log(n))` cho việc chèn, tra cứu và xóa. + +Trong tương lai gần, Ethereum có kế hoạch chuyển sang cấu trúc [Cây Verkle](/roadmap/verkle-trees), điều này sẽ mở ra nhiều khả năng mới cho các cải tiến giao thức trong tương lai. + +## Điều kiện tiên quyết {#prerequisites} + +Để hiểu rõ hơn về trang này, bạn nên có kiến thức cơ bản về [các hàm băm](https://en.wikipedia.org/wiki/Hash_function), [cây Merkle](https://en.wikipedia.org/wiki/Merkle_tree), [cây (tries)](https://en.wikipedia.org/wiki/Trie) và [tuần tự hóa](https://en.wikipedia.org/wiki/Serialization). Bài viết này bắt đầu bằng phần mô tả về một [cây cơ số](https://en.wikipedia.org/wiki/Radix_tree) cơ bản, sau đó giới thiệu dần các sửa đổi cần thiết cho cấu trúc dữ liệu được tối ưu hóa hơn của Ethereum. + +## Các cây cơ số cơ bản {#basic-radix-tries} + +Trong một cây cơ số cơ bản, mọi nút trông như sau: + +``` + [i_0, i_1 ... i_n, value] +``` + +Trong đó `i_0 ...` i_n`biểu thị các ký hiệu của bảng chữ cái (thường là nhị phân hoặc thập lục phân),`value`là giá trị cuối tại nút, và các giá trị trong`i_0, i_1 ...` các vị trí i_n` là `NULL` hoặc con trỏ tới (trong trường hợp của chúng ta là băm của) các nút khác. Điều này tạo thành một kho lưu trữ `(khóa, giá trị)` cơ bản. + +Giả sử bạn muốn sử dụng cấu trúc dữ liệu cây cơ số để duy trì một thứ tự trên một tập hợp các cặp khóa-giá trị. Để tìm giá trị hiện được ánh xạ tới khóa `dog` trong cây, trước tiên bạn sẽ chuyển đổi `dog` thành các chữ cái của bảng chữ cái (cho ra `64 6f 67`), sau đó đi xuống cây theo đường dẫn đó cho đến khi bạn tìm thấy giá trị. Nghĩa là, bạn bắt đầu bằng cách tra cứu băm gốc trong một DB khóa/giá trị phẳng để tìm nút gốc của cây. Nó được biểu diễn dưới dạng một mảng các khóa trỏ đến các nút khác. Bạn sẽ sử dụng giá trị tại chỉ mục `6` làm khóa và tra cứu nó trong DB khóa/giá trị phẳng để lấy nút ở cấp thấp hơn. Sau đó chọn chỉ mục `4` để tra cứu giá trị tiếp theo, rồi chọn chỉ mục `6`, v.v., cho đến khi, sau khi bạn đi theo đường dẫn: `root -> 6 -> 4 -> 6 -> 15 -> 6 -> 7`, bạn sẽ tra cứu giá trị của nút và trả về kết quả. + +Có sự khác biệt giữa việc tra cứu một cái gì đó trong 'cây' và 'DB' khóa/giá trị phẳng cơ bản. Cả hai đều xác định các sắp xếp khóa/giá trị, nhưng DB cơ bản có thể thực hiện tra cứu 1 bước truyền thống cho một khóa. Việc tra cứu một khóa trong cây đòi hỏi nhiều lần tra cứu DB cơ bản để đến được giá trị cuối cùng được mô tả ở trên. Hãy gọi cái sau là `path` để loại bỏ sự mơ hồ. + +Các thao tác cập nhật và xóa đối với cây cơ số có thể được định nghĩa như sau: + +```python + def update(node_hash, path, value): + curnode = db.get(node_hash) if node_hash else [NULL] * 17 + newnode = curnode.copy() + if path == "": + newnode[-1] = value + else: + newindex = update(curnode[path[0]], path[1:], value) + newnode[path[0]] = newindex + db.put(hash(newnode), newnode) + return hash(newnode) + + def delete(node_hash, path): + if node_hash is NULL: + return NULL + else: + curnode = db.get(node_hash) + newnode = curnode.copy() + if path == "": + newnode[-1] = NULL + else: + newindex = delete(curnode[path[0]], path[1:]) + newnode[path[0]] = newindex + + if all(x is NULL for x in newnode): + return NULL + else: + db.put(hash(newnode), newnode) + return hash(newnode) +``` + +Một cây cơ số "Merkle" được xây dựng bằng cách liên kết các nút sử dụng các thông báo băm mật mã được tạo ra một cách xác định. Việc định địa chỉ nội dung này (trong DB khóa/giá trị `khóa == keccak256(rlp(giá trị))`) cung cấp một sự đảm bảo toàn vẹn bằng mật mã của dữ liệu được lưu trữ. Nếu băm gốc của một cây cho trước được biết đến công khai, thì bất kỳ ai có quyền truy cập vào dữ liệu lá cơ bản đều có thể xây dựng một bằng chứng rằng cây bao gồm một giá trị nhất định tại một đường dẫn cụ thể bằng cách cung cấp các băm của mỗi nút nối một giá trị cụ thể với gốc cây. + +Kẻ tấn công không thể cung cấp bằng chứng về một cặp `(đường dẫn, giá trị)` không tồn tại vì băm gốc cuối cùng dựa trên tất cả các băm bên dưới nó. Bất kỳ sửa đổi cơ bản nào cũng sẽ thay đổi băm gốc. Bạn có thể nghĩ về băm như một biểu diễn nén của thông tin cấu trúc về dữ liệu, được bảo mật bởi sự bảo vệ tiền ảnh của hàm băm. + +Chúng ta sẽ gọi một đơn vị nguyên tử của cây cơ số (ví dụ: một ký tự thập lục phân đơn, hoặc số nhị phân 4 bit) là một "nibble". Trong khi duyệt một đường dẫn mỗi lần một nibble, như đã mô tả ở trên, các nút có thể tham chiếu tối đa đến 16 con nhưng bao gồm một phần tử `value`. Do đó, chúng ta biểu diễn chúng dưới dạng một mảng có độ dài 17. Chúng ta gọi các mảng 17 phần tử này là "nút nhánh". + +## Cây Merkle Patricia {#merkle-patricia-trees} + +Các cây cơ số có một hạn chế lớn: chúng không hiệu quả. Nếu bạn muốn lưu trữ một liên kết `(đường dẫn, giá trị)` trong đó đường dẫn, giống như trong Ethereum, dài 64 ký tự (số lượng nibble trong `bytes32`), chúng ta sẽ cần hơn một kilobyte dung lượng bổ sung để lưu trữ một cấp cho mỗi ký tự, và mỗi lần tra cứu hoặc xóa sẽ mất đủ 64 bước. Cây Patricia được giới thiệu sau đây sẽ giải quyết vấn đề này. + +### Tối ưu hóa {#optimization} + +Một nút trong một cây Merkle Patricia là một trong những loại sau: + +1. `NULL` (được biểu thị bằng chuỗi trống) +2. `branch` Một nút 17 mục `[ v0 ...` v15, vt ]` +3. `leaf` Một nút 2 mục `[ encodedPath, value ]` +4. `extension` Một nút 2 mục `[ encodedPath, key ]` + +Với các đường dẫn 64 ký tự, không thể tránh khỏi việc sau khi duyệt qua vài lớp đầu tiên của cây, bạn sẽ đến một nút nơi không có đường dẫn phân kỳ nào tồn tại ít nhất một phần đường đi xuống. Để tránh phải tạo ra tới 15 nút `NULL` thưa thớt dọc theo đường dẫn, chúng tôi rút ngắn đường đi xuống bằng cách thiết lập một nút `extension` có dạng `[ encodedPath, key ]`, trong đó `encodedPath` chứa "đường dẫn một phần" để bỏ qua (sử dụng một mã hóa nhỏ gọn được mô tả bên dưới) và `key` dùng cho lần tra cứu DB tiếp theo. + +Đối với một nút `leaf`, có thể được đánh dấu bằng một cờ trong nibble đầu tiên của `encodedPath`, đường dẫn mã hóa tất cả các đoạn đường dẫn của nút trước đó và chúng ta có thể tra cứu trực tiếp `value`. + +Tuy nhiên, việc tối ưu hóa trên lại gây ra sự mơ hồ. + +Khi duyệt các đường dẫn theo nibble, chúng ta có thể kết thúc với một số lượng nibble lẻ cần duyệt, nhưng vì tất cả dữ liệu được lưu trữ ở định dạng `bytes`. Không thể phân biệt được, chẳng hạn, giữa nibble `1` và các nibble `01` (cả hai đều phải được lưu trữ là `<01>`). Để chỉ định độ dài lẻ, đường dẫn một phần được đặt trước bằng một cờ. + +### Đặc tả: Mã hóa nhỏ gọn của chuỗi hex với dấu kết thúc tùy chọn {#specification} + +Việc gắn cờ cho cả _độ dài đường dẫn một phần còn lại là lẻ so với chẵn_ và _nút lá so với nút mở rộng_ như được mô tả ở trên nằm ở nibble đầu tiên của đường dẫn một phần của bất kỳ nút 2 mục nào. Chúng dẫn đến kết quả sau: + +| ký tự hex | bit | loại nút | độ dài đường dẫn | +| --------- | ---- | -------------------------------- | ---------------- | +| 0 | 0000 | mở rộng | chẵn | +| 1 | 0001 | mở rộng | lẻ | +| 2 | 0010 | kết thúc (lá) | chẵn | +| 3 | 0011 | kết thúc (lá) | lẻ | + +Đối với độ dài đường dẫn còn lại là chẵn (`0` hoặc `2`), một nibble "đệm" `0` khác sẽ luôn theo sau. + +```python + def compact_encode(hexarray): + term = 1 if hexarray[-1] == 16 else 0 + if term: + hexarray = hexarray[:-1] + oddlen = len(hexarray) % 2 + flags = 2 * term + oddlen + if oddlen: + hexarray = [flags] + hexarray + else: + hexarray = [flags] + [0] + hexarray + # hexarray now has an even length whose first nibble is the flags. + o = "" + for i in range(0, len(hexarray), 2): + o += chr(16 * hexarray[i] + hexarray[i + 1]) + return o +``` + +Ví dụ: + +```python + > [1, 2, 3, 4, 5, ...] + '11 23 45' + > [0, 1, 2, 3, 4, 5, ...] + '00 01 23 45' + > [0, f, 1, c, b, 8, 10] + '20 0f 1c b8' + > [f, 1, c, b, 8, 10] + '3f 1c b8' +``` + +Đây là mã mở rộng để lấy một nút trong cây Merkle Patricia: + +```python + def get_helper(node_hash, path): + if path == []: + return node_hash + if node_hash == "": + return "" + curnode = rlp.decode(node_hash if len(node_hash) < 32 else db.get(node_hash)) + if len(curnode) == 2: + (k2, v2) = curnode + k2 = compact_decode(k2) + if k2 == path[: len(k2)]: + return get(v2, path[len(k2) :]) + else: + return "" + elif len(curnode) == 17: + return get_helper(curnode[path[0]], path[1:]) + + def get(node_hash, path): + path2 = [] + for i in range(len(path)): + path2.push(int(ord(path[i]) / 16)) + path2.push(ord(path[i]) % 16) + path2.push(16) + return get_helper(node_hash, path2) +``` + +### Ví dụ về cây {#example-trie} + +Giả sử chúng ta muốn có một cây chứa bốn cặp đường dẫn/giá trị `('do', 'verb')`, `('dog', 'puppy')`, `('doge', 'coins')`, `('horse', 'stallion')`. + +Đầu tiên, chúng ta chuyển đổi cả đường dẫn và giá trị thành `bytes`. Dưới đây, các biểu diễn byte thực tế cho _đường dẫn_ được biểu thị bằng `<>`, mặc dù _giá trị_ vẫn được hiển thị dưới dạng chuỗi, được biểu thị bằng `''`, để dễ hiểu hơn (chúng thực sự cũng sẽ là `bytes`): + +``` + <64 6f> : 'verb' + <64 6f 67> : 'puppy' + <64 6f 67 65> : 'coins' + <68 6f 72 73 65> : 'stallion' +``` + +Bây giờ, chúng ta xây dựng một cây như vậy với các cặp khóa/giá trị sau trong DB cơ bản: + +``` + rootHash: [ <16>, hashA ] + hashA: [ <>, <>, <>, <>, hashB, <>, <>, <>, [ <20 6f 72 73 65>, 'stallion' ], <>, <>, <>, <>, <>, <>, <>, <> ] + hashB: [ <00 6f>, hashC ] + hashC: [ <>, <>, <>, <>, <>, <>, hashD, <>, <>, <>, <>, <>, <>, <>, <>, <>, 'verb' ] + hashD: [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coins' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ] +``` + +Khi một nút được tham chiếu bên trong một nút khác, những gì được bao gồm là `keccak256(rlp.encode(node))`, nếu `len(rlp.encode(node)) >= 32` thì ngược lại là `node`, trong đó `rlp.encode` là hàm mã hóa [RLP](/developers/docs/data-structures-and-encoding/rlp). + +Lưu ý rằng khi cập nhật một cây, người ta cần lưu trữ cặp khóa/giá trị `(keccak256(x), x)` trong một bảng tra cứu liên tục _nếu_ nút mới được tạo có độ dài >= 32. Tuy nhiên, nếu nút ngắn hơn, người ta không cần phải lưu trữ bất cứ điều gì, vì hàm f(x) = x là có thể đảo ngược. + +## Các cây trong Ethereum {#tries-in-ethereum} + +Tất cả các cây merkle trong lớp thực thi của Ethereum đều sử dụng Cây Merkle Patricia. + +Từ một tiêu đề khối có 3 gốc từ 3 trong số các cây này. + +1. stateRoot +2. transactionsRoot +3. receiptsRoot + +### Cây trạng thái {#state-trie} + +Có một cây trạng thái toàn cục, và nó được cập nhật mỗi khi một ứng dụng xử lý một khối. Trong đó, một `path` luôn là: `keccak256(ethereumAddress)` và một `value` luôn là: `rlp(ethereumAccount)`. Cụ thể hơn, một `tài khoản` Ethereum là một mảng 4 mục gồm `[nonce,balance,storageRoot,codeHash]`. Tại thời điểm này, cần lưu ý rằng `storageRoot` này là gốc của một cây patricia khác: + +### Cây lưu trữ {#storage-trie} + +Cây lưu trữ là nơi _tất cả_ dữ liệu hợp đồng tồn tại. Có một cây lưu trữ riêng cho mỗi tài khoản. Để truy xuất các giá trị tại các vị trí lưu trữ cụ thể tại một địa chỉ nhất định, cần có địa chỉ lưu trữ, vị trí số nguyên của dữ liệu được lưu trữ trong bộ lưu trữ và ID khối. Sau đó, chúng có thể được chuyển làm đối số cho `eth_getStorageAt` được định nghĩa trong JSON-RPC API, ví dụ: để truy xuất dữ liệu trong vị trí lưu trữ 0 cho địa chỉ `0x295a70b2de5e3953354a6a8344e616ed314d7251`: + +```bash +curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545 + +{"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"} + +``` + +Việc truy xuất các phần tử khác trong bộ lưu trữ phức tạp hơn một chút vì trước tiên phải tính toán vị trí trong cây lưu trữ. Vị trí được tính bằng băm `keccak256` của địa chỉ và vị trí lưu trữ, cả hai đều được đệm bên trái bằng các số không cho đến độ dài 32 byte. Ví dụ: vị trí của dữ liệu trong vị trí lưu trữ 1 cho địa chỉ `0x391694e7e0b0cce554cb130d723a9d27458f9298` là: + +```python +keccak256(decodeHex("000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001")) +``` + +Trong bảng điều khiển Geth, điều này có thể được tính như sau: + +``` +> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001" +undefined +> web3.sha3(key, {"encoding": "hex"}) +"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9" +``` + +`path` do đó là `keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)`. Bây giờ có thể sử dụng điều này để truy xuất dữ liệu từ cây lưu trữ như trước: + +```bash +curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545 + +{"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"} +``` + +Lưu ý: `storageRoot` cho một tài khoản Ethereum mặc định là trống nếu đó không phải là tài khoản hợp đồng. + +### Cây giao dịch {#transaction-trie} + +Có một cây giao dịch riêng cho mỗi khối, lại lưu trữ các cặp `(khóa, giá trị)`. Một đường dẫn ở đây là: `rlp(transactionIndex)` đại diện cho khóa tương ứng với một giá trị được xác định bởi: + +```python +if legacyTx: + value = rlp(tx) +else: + value = TxType | encode(tx) +``` + +Thông tin thêm về điều này có thể được tìm thấy trong tài liệu [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718). + +### Cây biên lai {#receipts-trie} + +Mỗi khối có cây Biên lai riêng. Một `path` ở đây là: `rlp(transactionIndex)`. `transactionIndex` là chỉ mục của nó trong khối mà nó được bao gồm. Cây biên lai không bao giờ được cập nhật. Tương tự như cây Giao dịch, có các biên lai hiện tại và cũ. Để truy vấn một biên lai cụ thể trong cây Biên lai, cần có chỉ mục của giao dịch trong khối của nó, tải trọng biên lai và loại giao dịch. Biên lai được trả về có thể thuộc loại `Receipt` được định nghĩa là sự nối chuỗi của `TransactionType` và `ReceiptPayload` hoặc nó có thể thuộc loại `LegacyReceipt` được định nghĩa là `rlp([status, cumulativeGasUsed, logsBloom, logs])`. + +Thông tin thêm về điều này có thể được tìm thấy trong tài liệu [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718). + +## Đọc thêm {#further-reading} + +- [Cây Merkle Patricia đã sửa đổi — Cách Ethereum lưu một trạng thái](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd) +- [Merkling trong Ethereum](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/) +- [Tìm hiểu về cây Ethereum](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/) diff --git a/public/content/translations/vi/developers/docs/data-structures-and-encoding/rlp/index.md b/public/content/translations/vi/developers/docs/data-structures-and-encoding/rlp/index.md new file mode 100644 index 00000000000..ec1780d5dc1 --- /dev/null +++ b/public/content/translations/vi/developers/docs/data-structures-and-encoding/rlp/index.md @@ -0,0 +1,163 @@ +--- +title: Recursive-length prefix (RLP) serialization +description: "Giải thích về mã hóa rlp trong excution layer của Ethereum." +lang: vi +sidebarDepth: 2 +--- + +Recursive Length Prefix (RLP) serialization được sử dụng phổ biến trong các execution client của Ethereum. RLP chuẩn hóa việc truyền dữ liệu giữa các node với một định dạng tiết kiệm không gian. Mục đích của RLP là mã hóa các mảng dữ liệu nhị phân lồng nhau bất kỳ, và RLP là phương thức mã hóa chính được sử dụng để tuần tự hóa các đối tượng trong excution layer của Ethereum. Mục đích chính của RLP là mã hóa cấu trúc; ngoại trừ các số nguyên dương, RLP ủy thác việc mã hóa các kiểu dữ liệu cụ thể (ví dụ: chuỗi, số thực) cho các giao thức bậc cao hơn. Các số nguyên dương phải được biểu diễn dưới dạng nhị phân big-endian không có số không ở đầu (do đó làm cho giá trị số nguyên không tương đương với mảng byte trống). Các số nguyên dương được giải tuần tự hóa có số không ở đầu phải bị coi là không hợp lệ bởi bất kỳ giao thức bậc cao nào sử dụng RLP. + +Thông tin thêm trong [sách vàng Ethereum (Phụ lục B)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19). + +Để sử dụng RLP để mã hóa một dictionary, 2 chuẩn được sử dụng là: + +- sử dụng `[[k1,v1],[k2,v2]...]` với các khóa theo thứ tự từ điển +- sử dụng mã hóa Patricia Tree bậc cao như Ethereum + +## Định nghĩa {#definition} + +Phương thức mã hóa RLP lấy một item. Một item được định nghĩa như sau： + +- một chuỗi (tức là mảng byte) là một mục +- một list các item là một item +- một số nguyên dương là một mục + +Ví dụ, tất cả các mục dưới đều là item: + +- một chuỗi rỗng; +- chuỗi chứa từ "cat"; +- một list chứa số lượng chuỗi bất kỳ; +- và các cấu trúc dữ liệu phức tạp hơn như `["cat", ["puppy", "cow"], "horse", [[]], "pig", [""], "sheep"]`. +- số `100` + +Lưu ý rằng trong ngữ cảnh của phần còn lại của trang này, 'chuỗi' có nghĩa là "một số byte dữ liệu nhị phân nhất định"; không có mã hóa đặc biệt nào được sử dụng và không có kiến thức nào về nội dung của các chuỗi được ngụ ý (ngoại trừ theo yêu cầu của quy tắc chống lại các số nguyên dương không tối thiểu). + +Mã hóa RLP được định nghĩa như sau: + +- Đối với một số nguyên dương, nó được chuyển đổi thành mảng byte ngắn nhất mà diễn giải big-endian của nó là số nguyên, và sau đó được mã hóa thành một chuỗi theo các quy tắc bên dưới. +- Đối với một byte đơn có giá trị trong phạm vi `[0x00, 0x7f]` (thập phân `[0, 127]`), byte đó là mã hóa RLP của chính nó. +- Nếu không, nếu một chuỗi dài 0-55 byte, mã hóa RLP bao gồm một byte đơn có giá trị **0x80** (hệ thập phân 128) cộng với độ dài của chuỗi, theo sau là chuỗi. Do đó, phạm vi của byte đầu tiên là `[0x80, 0xb7]` (hệ thập phân `[128, 183]`). +- Nếu một chuỗi dài hơn 55 byte, mã hóa RLP bao gồm một byte đơn có giá trị **0xb7** (hệ thập phân 183) cộng với độ dài tính bằng byte của độ dài chuỗi ở dạng nhị phân, theo sau là độ dài của chuỗi, theo sau là chuỗi. Ví dụ: một chuỗi dài 1024 byte sẽ được mã hóa là `\xb9\x04\x00` (hệ thập phân `185, 4, 0`) theo sau là chuỗi. Ở đây, `0xb9` (183 + 2 = 185) là byte đầu tiên, theo sau là 2 byte `0x0400` (hệ thập phân 1024) biểu thị độ dài của chuỗi thực tế. Do đó, phạm vi của byte đầu tiên là `[0xb8, 0xbf]` (hệ thập phân `[184, 191]`). +- Nếu một chuỗi dài 2^64 byte, hoặc dài hơn, nó có thể không được mã hóa. +- Nếu tổng tải trọng của một danh sách (tức là tổng độ dài của tất cả các mục được mã hóa RLP) dài 0-55 byte, mã hóa RLP bao gồm một byte đơn có giá trị **0xc0** cộng với độ dài của tải trọng, theo sau là sự nối tiếp của các mã hóa RLP của các mục. Do đó, phạm vi của byte đầu tiên là `[0xc0, 0xf7]` (hệ thập phân `[192, 247]`). +- Nếu tổng tải trọng của một danh sách dài hơn 55 byte, mã hóa RLP bao gồm một byte đơn có giá trị **0xf7** cộng với độ dài tính bằng byte của độ dài tải trọng ở dạng nhị phân, theo sau là độ dài của tải trọng, theo sau là sự nối tiếp của các mã hóa RLP của các mục. Do đó, phạm vi của byte đầu tiên là `[0xf8, 0xff]` (hệ thập phân `[248, 255]`). + +Đây là trong code: + +```python +def rlp_encode(input): + if isinstance(input,str): + if len(input) == 1 and ord(input) < 0x80: + return input + return encode_length(len(input), 0x80) + input + elif isinstance(input, list): + output = '' + for item in input: + output += rlp_encode(item) + return encode_length(len(output), 0xc0) + output + +def encode_length(L, offset): + if L < 56: + return chr(L + offset) + elif L < 256**8: + BL = to_binary(L) + return chr(len(BL) + offset + 55) + BL + raise Exception("input too long") + +def to_binary(x): + if x == 0: + return '' + return to_binary(int(x / 256)) + chr(x % 256) +``` + +## Ví dụ {#examples} + +- chuỗi "dog" = [ 0x83, 'd', 'o', 'g' ] +- danh sách [ "cat", "dog" ] = `[ 0xc8, 0x83, 'c', 'a', 't', 0x83, 'd', 'o', 'g' ]` +- chuỗi trống ('null') = `[ 0x80 ]` +- danh sách trống = `[ 0xc0 ]` +- số nguyên 0 = `[ 0x80 ]` +- byte '\\x00' = `[ 0x00 ]` +- byte '\\x0f' = `[ 0x0f ]` +- các byte '\\x04\\x00' = `[ 0x82, 0x04, 0x00 ]` +- [biểu diễn lý thuyết tập hợp](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers) của ba, `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` +- chuỗi "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ...` , 'e', 'l', 'i', 't' ]` + +## Giải mã RLP {#rlp-decoding} + +Dựa theo các quy tắc và quy trình mã hóa RLP, đầu vào của mã hóa RLP được coi là một mảng dữ liệu nhị phân. Quá trình giải mã hóa RLP như sau: + +1. theo byte đầu tiên (tức là tiền tố) của dữ liệu đầu vào và giải mã kiểu dữ liệu, độ dài của dữ liệu thực tế và độ lệch; + +2. theo loại và độ lệch của dữ liệu, giải mã dữ liệu tương ứng, tuân thủ quy tắc mã hóa tối thiểu cho các số nguyên dương; + +3. tiếp tục giải mã hóa phần còn lại của đầu vào; + +Trong số đó, các quy tắc giải mã kiểu dữ liệu và offset như sau: + +1. dữ liệu là một chuỗi nếu phạm vi của byte đầu tiên (tức là tiền tố) là [0x00, 0x7f] và chuỗi chính xác là chính byte đầu tiên đó; + +2. dữ liệu là một chuỗi nếu phạm vi của byte đầu tiên là [0x80, 0xb7] và chuỗi có độ dài bằng byte đầu tiên trừ đi 0x80 theo sau byte đầu tiên; + +3. dữ liệu là một chuỗi nếu phạm vi của byte đầu tiên là [0xb8, 0xbf] và độ dài của chuỗi có độ dài tính bằng byte bằng byte đầu tiên trừ đi 0xb7 theo sau byte đầu tiên và chuỗi theo độ dài của chuỗi; + +4. dữ liệu là một list nếu phạm vi của byte đầu tiên là [0xc0, 0xf7], và phần mã hóa rlp của tất cả item của list có độ lớn băngf byte đầu tiên trừ 0xc0 theo sau byte đầu tiên; + +5. dữ liệu là một list nếu phạm vi của byte đầu tiên là [0xb8, 0xff] và toàn bộ payload của list có độ dài bằng byte đầu tiên trừ đi 0xf7 theo sau byte đầu tiên, và các mã hóa rlp của các item nối tiếp nhau nằm tiếp sau; + +Đây là trong code: + +```python +def rlp_decode(input): + if len(input) == 0: + return + output = '' + (offset, dataLen, type) = decode_length(input) + if type is str: + output = instantiate_str(substr(input, offset, dataLen)) + elif type is list: + output = instantiate_list(substr(input, offset, dataLen)) + output += rlp_decode(substr(input, offset + dataLen)) + return output + +def decode_length(input): + length = len(input) + if length == 0: + raise Exception("input is null") + prefix = ord(input[0]) + if prefix <= 0x7f: + return (0, 1, str) + elif prefix <= 0xb7 and length > prefix - 0x80: + strLen = prefix - 0x80 + return (1, strLen, str) + elif prefix <= 0xbf and length > prefix - 0xb7 and length > prefix - 0xb7 + to_integer(substr(input, 1, prefix - 0xb7)): + lenOfStrLen = prefix - 0xb7 + strLen = to_integer(substr(input, 1, lenOfStrLen)) + return (1 + lenOfStrLen, strLen, str) + elif prefix <= 0xf7 and length > prefix - 0xc0: + listLen = prefix - 0xc0; + return (1, listLen, list) + elif prefix <= 0xff and length > prefix - 0xf7 and length > prefix - 0xf7 + to_integer(substr(input, 1, prefix - 0xf7)): + lenOfListLen = prefix - 0xf7 + listLen = to_integer(substr(input, 1, lenOfListLen)) + return (1 + lenOfListLen, listLen, list) + raise Exception("input does not conform to RLP encoding form") + +def to_integer(b): + length = len(b) + if length == 0: + raise Exception("input is null") + elif length == 1: + return ord(b[0]) + return ord(substr(b, -1)) + to_integer(substr(b, 0, -1)) * 256 +``` + +## Đọc thêm {#further-reading} + +- [RLP trong Ethereum](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919) +- [Hậu trường Ethereum: RLP](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58) +- [Coglio, A. (2020). Ethereum's Recursive Length Prefix in ACL2. arXiv preprint arXiv:2009.13769.](https://arxiv.org/abs/2009.13769) + +## Các chủ đề liên quan {#related-topics} + +- [Cây Merkle Patricia](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) From c4abddd48dbde03a2dfea4930c052797bfd7cea5 Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Mon, 16 Feb 2026 11:13:45 +0000 Subject: [PATCH 2/2] fix(i18n): correct typos in Vietnamese translations --- .../content/translations/vi/developers/docs/dapps/index.md | 2 +- .../docs/data-structures-and-encoding/rlp/index.md | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/public/content/translations/vi/developers/docs/dapps/index.md b/public/content/translations/vi/developers/docs/dapps/index.md index 9d1dd488f2a..f52edee8114 100644 --- a/public/content/translations/vi/developers/docs/dapps/index.md +++ b/public/content/translations/vi/developers/docs/dapps/index.md @@ -38,7 +38,7 @@ Smartcontract là những code thực thi trên Ethereum blockchain và chạy c ## Nhược điểm của việc phát triển ứng dụng phi tập trung {#drawbacks-of-dapp-development} - **Bảo trì** – Các ứng dụng phi tập trung có thể khó bảo trì hơn vì mã và dữ liệu được công bố trên chuỗi khối khó sửa đổi hơn. Các developes khó có thể update dapp của họ sau khi chúng được release, ngay cả khi lỗi hoặc rủi ro bảo mật được xác định trong phiên bản cũ. -- **Chi phí hiệu suất** – Có một chi phí hiệu suất rất lớn, và việc thay đổi quy mô là thực sự khó khăn. Để đạt được tính bảo mật, tính toàn vẹn và tính minh bạch mà Ethereum mong muốn thì các node đều chaỵ và lưu trữ mọi giao dịch. Cơ chế đồng thuận bằng chứng cổ phần cũng cần có thời gian. +- **Chi phí hiệu suất** – Có một chi phí hiệu suất rất lớn, và việc thay đổi quy mô là thực sự khó khăn. Để đạt được tính bảo mật, tính toàn vẹn và tính minh bạch mà Ethereum mong muốn thì các node đều chạy và lưu trữ mọi giao dịch. Cơ chế đồng thuận bằng chứng cổ phần cũng cần có thời gian. - **Tắc nghẽn mạng** – Khi một ứng dụng phi tập trung sử dụng quá nhiều tài nguyên tính toán, toàn bộ mạng sẽ bị tắc nghẽn. Hiện tại, theo tính toán thì network có thể xử lý khoảng 10-15 giao dịch mỗi giây. Nếu các yêu cầu giao dịch nhanh hơn mức này, nhóm các giao dịch chưa được xử lý sẽ nhanh chóng tăng vọt. - **Trải nghiệm người dùng** – Có thể khó hơn để thiết kế các trải nghiệm thân thiện với người dùng vì người dùng cuối thông thường có thể thấy quá khó để thiết lập một bộ công cụ cần thiết để tương tác với chuỗi khối một cách thực sự an toàn. - **Tập trung hóa** – Các giải pháp thân thiện với người dùng và nhà phát triển được xây dựng trên lớp cơ sở của Ethereum cuối cùng có thể trông giống như các dịch vụ tập trung. Ví dụ: các dịch vụ như vậy có thể lưu trữ khóa hoặc thông tin nhạy cảm khác ở phía máy chủ, phục vụ giao diện người dùng sử dụng máy chủ tập trung hoặc chạy logic nghiệp vụ quan trọng trên máy chủ tập trung trước khi ghi vào chuỗi khối. Tập trung hóa loại bỏ nhiều (nếu không phải tất cả) những lợi thế của blockchain so với mô hình truyền thống. diff --git a/public/content/translations/vi/developers/docs/data-structures-and-encoding/rlp/index.md b/public/content/translations/vi/developers/docs/data-structures-and-encoding/rlp/index.md index ec1780d5dc1..dc1bb4e26b8 100644 --- a/public/content/translations/vi/developers/docs/data-structures-and-encoding/rlp/index.md +++ b/public/content/translations/vi/developers/docs/data-structures-and-encoding/rlp/index.md @@ -1,11 +1,11 @@ --- title: Recursive-length prefix (RLP) serialization -description: "Giải thích về mã hóa rlp trong excution layer của Ethereum." +description: "Giải thích về mã hóa rlp trong execution layer của Ethereum." lang: vi sidebarDepth: 2 --- -Recursive Length Prefix (RLP) serialization được sử dụng phổ biến trong các execution client của Ethereum. RLP chuẩn hóa việc truyền dữ liệu giữa các node với một định dạng tiết kiệm không gian. Mục đích của RLP là mã hóa các mảng dữ liệu nhị phân lồng nhau bất kỳ, và RLP là phương thức mã hóa chính được sử dụng để tuần tự hóa các đối tượng trong excution layer của Ethereum. Mục đích chính của RLP là mã hóa cấu trúc; ngoại trừ các số nguyên dương, RLP ủy thác việc mã hóa các kiểu dữ liệu cụ thể (ví dụ: chuỗi, số thực) cho các giao thức bậc cao hơn. Các số nguyên dương phải được biểu diễn dưới dạng nhị phân big-endian không có số không ở đầu (do đó làm cho giá trị số nguyên không tương đương với mảng byte trống). Các số nguyên dương được giải tuần tự hóa có số không ở đầu phải bị coi là không hợp lệ bởi bất kỳ giao thức bậc cao nào sử dụng RLP. +Recursive Length Prefix (RLP) serialization được sử dụng phổ biến trong các execution client của Ethereum. RLP chuẩn hóa việc truyền dữ liệu giữa các node với một định dạng tiết kiệm không gian. Mục đích của RLP là mã hóa các mảng dữ liệu nhị phân lồng nhau bất kỳ, và RLP là phương thức mã hóa chính được sử dụng để tuần tự hóa các đối tượng trong execution layer của Ethereum. Mục đích chính của RLP là mã hóa cấu trúc; ngoại trừ các số nguyên dương, RLP ủy thác việc mã hóa các kiểu dữ liệu cụ thể (ví dụ: chuỗi, số thực) cho các giao thức bậc cao hơn. Các số nguyên dương phải được biểu diễn dưới dạng nhị phân big-endian không có số không ở đầu (do đó làm cho giá trị số nguyên không tương đương với mảng byte trống). Các số nguyên dương được giải tuần tự hóa có số không ở đầu phải bị coi là không hợp lệ bởi bất kỳ giao thức bậc cao nào sử dụng RLP. Thông tin thêm trong [sách vàng Ethereum (Phụ lục B)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19). @@ -101,7 +101,7 @@ Trong số đó, các quy tắc giải mã kiểu dữ liệu và offset như sa 3. dữ liệu là một chuỗi nếu phạm vi của byte đầu tiên là [0xb8, 0xbf] và độ dài của chuỗi có độ dài tính bằng byte bằng byte đầu tiên trừ đi 0xb7 theo sau byte đầu tiên và chuỗi theo độ dài của chuỗi; -4. dữ liệu là một list nếu phạm vi của byte đầu tiên là [0xc0, 0xf7], và phần mã hóa rlp của tất cả item của list có độ lớn băngf byte đầu tiên trừ 0xc0 theo sau byte đầu tiên; +4. dữ liệu là một list nếu phạm vi của byte đầu tiên là [0xc0, 0xf7], và phần mã hóa rlp của tất cả item của list có độ lớn bằng byte đầu tiên trừ 0xc0 theo sau byte đầu tiên; 5. dữ liệu là một list nếu phạm vi của byte đầu tiên là [0xb8, 0xff] và toàn bộ payload của list có độ dài bằng byte đầu tiên trừ đi 0xf7 theo sau byte đầu tiên, và các mã hóa rlp của các item nối tiếp nhau nằm tiếp sau;