Klaytn Docs Archive VN
  • Tài liệu của Klaytn
  • -
    • Tổng quan về Klaytn
      • Tại sao nên chọn Klaytn
      • Thiết kế của Klaytn
        • Cơ chế đồng thuận
        • Tài khoản
        • Giao dịch
          • Cơ bản
          • Ủy thác phí
          • Ủy thác phí một phần
          • Ethereum
        • Tính toán
          • Hợp đồng thông mình Klaytn
          • Mô hình thực thi
          • Chi phí tính toán
            • Chi phí tính toán (Các tài liệu trước)
          • Máy ảo Klaytn
            • Máy ảo Klaytn (Các tài liệu trước)
        • Lưu trữ
        • Phí giao dịch
          • Phí giao dịch (Các tài liệu trước)
        • Đồng tiền mặc định của Klaytn - KLAY
        • Nền kinh tế token
        • Quản trị
        • Đa kênh
        • KNI
      • Các giải pháp mở rộng
    • Bắt đầu
      • Triển khai hợp đồng thông minh bằng Foundry
      • Triển khai hợp đồng thông minh bằng Hardhat
      • Triển khai hợp đồng thông minh bằng KEN
        • Khởi chạy nút điểm cuối
        • Nạp tiền vào tài khoản
        • Cài đặt các công cụ phát triển
        • Triển khai hợp đồng thông minh
        • Kiểm tra quy trình triển khai
        • Quản lý tài khoản
          • Tạo tài khoản
          • Quản lý tài khoản
      • Môi trường phát triển
      • Nhận KLAY
    • Hợp đồng thông minh
      • Solidity - Ngôn ngữ của hợp đồng thông minh
      • Hợp đồng đã lập trước
        • Hợp đồng đã lập trước (Các tài liệu trước)
      • IDE và công cụ
        • Truffle
      • Hợp đồng mẫu
        • KlaytnGreeter
        • ERC-20
          • 1. Soạn hợp đồng thông minh ERC-20
          • 2. Triển khai hợp đồng thông minh
          • 3. Tương tác với token ERC-20 từ Ví Klaytn
        • ERC-721
          • 1. Soạn hợp đồng thông minh ERC-721
          • 2. Triển khai hợp đồng thông minh
      • Hướng dẫn kiểm thử
      • Hướng dẫn triển khai
      • Token tương thích Klaytn
      • Di chuyển hợp đồng Ethereum
    • Chạy một Node
      • Triển khai
        • Nút điểm cuối
          • Yêu cầu hệ thống
          • Hướng dẫn cài đặt
            • Tải xuống
            • Hướng dẫn cài đặt
            • Cấu hình
            • Khởi động EN
            • Thử việc cài đặt
          • các lệnh CLI ken
          • API JSON-RPC
        • Core Cell
          • Yêu cầu hệ thống
          • Cấu hình mạng
          • Hướng dẫn cài đặt
            • Tải xuống
            • Trước khi cài đặt
            • Thiết lập nút đồng thuận
              • Hướng dẫn cài đặt
              • Cấu hình
              • Khởi động CN
            • Thiết lập nút proxy
              • Hướng dẫn cài đặt
              • Cấu hình
              • Khởi động PN
            • Kiểm tra Core Cell
          • Giám sát thiết lập
          • Thiết lập H/A
        • Chuỗi dịch vụ
          • Bắt đầu
            • Thiết lập chuỗi dịch vụ 4 nút
            • Kết nối với Baobab
            • Chuyển giá trị chuỗi chéo
            • HA (Tính sẵn sàng cao) dành cho Chuỗi dịch vụ
            • Chuỗi dịch vụ lồng nhau
            • Chuyển giá trị giữa các chuỗi dịch vụ kết nối
          • Hướng dẫn sử dụng tham chiếu
            • Yêu cầu hệ thống
            • Tải xuống
            • Hướng dẫn sử dụng SCN
              • Cài đặt
              • Cấu hình
              • Bắt đầu/dừng SCN
              • Kiểm tra trạng thái nút
              • các lệnh kscn
              • các lệnh homi
            • Hướng dẫn sử dụng SPN/SEN
              • Cài đặt
              • Cấu hình
              • Bắt đầu/dừng nút
              • Kiểm tra trạng thái nút
            • Cấu hình cầu nối
            • Neo
            • Neo KAS
            • Chuyển giá trị
            • Tập tin cấu hình
            • Tập tin bản ghi
            • Genesis JSON
            • Nâng cấp & Nâng cấp căn bản
          • Hướng dẫn sử dụng
        • Tải Về Các Gói Dịch Vụ
          • v1.11.1
          • v1.11.0
          • v1.10.2
          • v1.10.1
          • v1.10.0
          • v1.9.1
          • v1.9.0
          • v1.8.4
          • v1.8.3
          • v1.8.2
          • v1.8.1
          • v1.8.0
          • v1.7.3
          • v1.7.2
          • v1.7.1
          • v1.7.0
          • v1.6.4
          • v1.6.3
          • v1.6.2
          • v1.6.1
          • v1.6.0
          • v1.5.3
          • v1.5.2
          • v1.5.1
          • v1.5.0
          • v1.4.2
          • v1.4.1
          • v1.4.0
          • v1.3.0
          • v1.2.0
          • v1.1.1
          • v1.0.0
          • v0.9.6
          • v0.8.2
    • Hướng dẫn hoạt động
      • Cấu hình
      • Nhật ký nút
      • Ghi bản ghi hoạt động
      • Lỗi & xử lý sự cố
      • Lệnh Klaytn
      • Thay đổi dữ liệu chuỗi
      • Di chuyển dữ liệu chuỗi
    • dApp Developers
      • API JSON-RPC
        • Tham chiếu API
          • eth
            • Cảnh báo
            • Tài khoản
            • Khối
            • Giao dịch
            • Cấu hình
            • Bộ lọc
            • Gas
            • Khác
          • klay
            • Tài khoản
            • Khối
            • Giao dịch
              • Làm việc với các loại giao dịch của Klaytn
            • Cấu hình
            • Bộ lọc
            • Gas
            • Khác
          • net
          • gỡ lỗi
            • Ghi bản ghi
            • Tạo hồ sơ
            • Theo dõi thời gian chạy
            • Gỡ lỗi thời gian chạy
            • Theo dõi VM
            • Theo dõi tiêu chuẩn VM
            • Kiểm tra chuỗi khối
          • quản trị viên
          • cá nhân
          • txpool
          • quản trị
        • Tham chiếu API chuỗi dịch vụ
          • cầu nối chính
          • cầu nối phụ
        • Mã lỗi giao dịch
      • Nhà cung cấp dịch vụ RPC
        • Điểm cuối công khai
      • SDK & thư viện để tương tác với Nút Klaytn
        • caver-js
          • Bắt đầu
          • Gửi giao dịch mẫu
          • Tham chiếu API
            • caver.tài khoản
            • caver.wallet
              • caver.wallet.keyring
            • caver.transaction
              • Cơ bản
              • Ủy thác phí
              • Ủy thác phí một phần
            • caver.rpc
              • caver.rpc.klay
              • caver.rpc.net
              • caver.rpc.governance
            • caver.contract
            • caver.abi
            • caver.kct
              • caver.kct.kip7
              • caver.kct.kip17
              • caver.kct.kip37
            • caver.validator
            • caver.utils
            • caver.ipfs
          • caver-js ~v1.4.1
            • Bắt đầu (~v1.4.1)
            • Tham chiếu API
              • caver.klay
                • Tài khoản
                • Khối
                • Giao dịch
                  • Cũ
                  • Chuyển giá trị
                  • Ghi chú về chuyển giá trị
                  • Cập nhật tài khoản
                  • Triển khai hợp đồng thông minh
                  • Thực thi hợp đồng thông minh
                  • Cancel
                • Cấu hình
                • Bộ lọc
                • Khác
              • caver.klay.net
              • caver.klay.tài khoảns
              • caver.klay.Contract
              • caver.klay.KIP7
              • caver.klay.KIP17
              • caver.klay.abi
              • caver.utils (~v1.4.1)
            • Di chuyển từ web3.js
        • caver-java
          • Bắt đầu
          • Tham chiếu API
          • caver-java ~v1.4.0
            • Bắt đầu (~v1.4.0)
            • Di chuyển từ web3j
        • ethers.js
        • web3.js
      • Hướng dẫn
        • Bộ công cụ trực tuyến của Klaytn
        • Ví dụ về ủy thác phí
        • Count DApp
          • 1. Thiết lập môi trường
          • 2. Sao chép Count DApp
          • 3. Cấu trúc thư mục
          • 4. Soạn hợp đồng thông minh
          • 5. Tổng quan về mã Frontend
            • 5-1. Thành phần số khối
            • 5-2. Thành phần xác thực
            • 5-3. Thành phần đếm
          • 6. Triển khai hợp đồng
          • 7. Chạy ứng dụng
        • Klaystagram
          • 1. Thiết lập môi trường
          • 2. Sao chép Klaystagram DApp
          • 3. Cấu trúc thư mục
          • 4. Soạn hợp đồng thông minh Klaystagram
          • 5. Triển khai hợp đồng
          • 6. Tổng quan về mã Frontend
          • 7. Trang thông tin
            • 7-1. Kết nối hợp đồng với Frontend
            • 7-2. Thành phần UploadPhoto
            • 7-3. Thành phần nguồn cấp dữ liệu
            • 7-4. Thành phần TransferOwnership
          • 8. Chạy ứng dụng
        • Building a Buy Me a Coffee dApp
          • 1. Project Setup
          • 2. Creating a BMC Smart Contract
          • 3. Testing the contract using scripts
          • 4. Deploying BMC Smart contract
          • 5. Building the BMC Frontend with React and Web3Onboard
          • 6. Deploying Frontend code on IPFS using Fleek
          • 7. Conclusion
        • Migrating Ethereum App to Klaytn
        • Connecting MetaMask
        • Connecting Remix
        • Verifying Smart Contracts Using Block Explorers
      • Công cụ dành cho nhà phát triển
        • Ví
          • Kaikas
          • Ví Klaytn
          • Két Klaytn
            • Thiết kế két Klaytn
            • Tạo két
            • Thêm tài sản
            • Gửi tài sản
            • Tương tác hợp đồng
            • Trình xây dựng giao dịch
            • Các điểm đến nút
            • Câu hỏi thường gặp
          • Thư Viện Ví
            • Web3Auth
            • Web3Modal
            • Web3-Onboard
        • Oracle
          • Hệ Thống Orakl
          • Witnet
          • SupraOracles
        • Trình duyệt khối
          • Klaytnscope
          • Klaytnfinder
        • Klaytn Contracts Wizard
    • Glossary
  • ---
    • Lịch sử nâng cấp căn bản của Klaytn
    • Klaytn 2.0
      • Gói Metaverse
      • Tính hoàn thiện và cải tiến
      • Tương thích với Ethereum
      • Quản trị phi tập trung
      • Quỹ sinh thái lớn
    • Câu hỏi thường gặp
    • Mã nguồn mở
    • Điều khoản sử dụng
    • Ngôn ngữ
  • ℹ️Latest Klaytn Docs
Powered by GitBook
On this page
  • Thông tin cơ bản
  • PBFT (Hệ thống chịu lỗi Byzantine thiết thực)
  • Cơ chế đồng thuận trong Klaytn
  1. -
  2. Tổng quan về Klaytn
  3. Thiết kế của Klaytn

Cơ chế đồng thuận

PreviousThiết kế của KlaytnNextTài khoản

Last updated 1 year ago

Cơ chế đồng thuận (thuật toán) là cách để đạt được sự đồng thuận giữa các thực thể mà không cần đến sự tin tưởng. Trong công nghệ chuỗi khối, cơ chế này được sử dụng để đạt được sự đồng thuận về việc một khối có hợp lệ hay không. Hiệu suất của các mạng chuỗi khối phụ thuộc vào hiệu suất của các cơ chế đồng thuận đã được thông qua và nó có tác động đáng kể đến khả năng sử dụng cảm nhận của các Ứng dụng chuỗi khối.

Mạng chính thức Cypress của Klaytn có hiệu suất như sau.

  • Xử lý hơn 4.000 giao dịch mỗi giây.

  • Hoàn thiện giao dịch tức thời.

  • Thời gian tạo khối một giây.

  • Hơn 50 nút đồng thuận có thể tham gia vào quá trình đồng thuận.

Trong tài liệu này, chúng ta sẽ tìm hiểu cách áp dụng quy trình đồng thuận hiệu suất cao của Klaytn.

Thông tin cơ bản

đang sử dụng (Bằng chứng công việc), trong khi Ethereum gần đây đã chuyển qua (Bằng chứng cổ phần), cơ chế này sẽ quyết định về các nút tạo khối bằng cổ phần của nút. Thông thường, các thuật toán này không cần đến hoạt động giao tiếp giữa các nút trong việc quyết định về tính hợp lệ của các khối.

Vì thế, trong các hệ thống này, một phân nhánh có thể phát sinh, nghĩa là có thể có từ hai khối khác nhau trở lên được tạo ra với cùng một chiều cao. Thông thường, quy tắc "chuỗi nào dài nhất sẽ là chuỗi hợp lệ" được áp dụng để xử lý tình trạng phân nhánh. Điều này có nghĩa là các phân nhánh này cuối cùng sẽ được hợp nhất thành một chuỗi chính tắc duy nhất, nhưng điều này cũng có nghĩa là danh sách các khối có thể được hoàn nguyên sau một khoảng thời gian nào đó khi nó thuộc về chuỗi ngắn hơn. Vì thế, trong các thuật toán này, không có gì đảm bảo được tính hoàn thiện của các khối và giao dịch. Tính hoàn thiện chỉ có thể đạt được theo xác suất sau một khoảng thời gian, điều này vẫn không thể được đảm bảo 100%.

Tình trạng thiếu tính hoàn thiện này là một vấn đề khó khăn đối với các dịch vụ lấy khách hàng làm trọng tâm có sử dụng nền tảng chuỗi khối. Điều này xảy ra là vì cần phải đợi cho đến khi các phân nhánh được giải quyết và có đủ khối được tạo ra sau giao dịch chuyển tiền để tin rằng giao dịch không thể đảo ngược. Điều này có tác động tiêu cực đến cả người dùng và nhà cung cấp dịch vụ.

Các dịch vụ tài chính có thể làm ví dụ minh họa đơn giản cho vấn đề này. Giả sử một người dùng chuyển tiền cho người khác và dịch vụ này không thể xác minh rằng giao dịch chuyển tiền đó là hợp lệ trong 30 đến 60 phút. Điều này xảy ra là vì cần phải đợi cho đến khi các phân nhánh đã được hợp nhất thành một chuỗi duy nhất và có một số khối đã được tạo ra sau giao dịch chuyển tiền để đảm bảo rằng giao dịch đó không thể đảo ngược.

PBFT (Hệ thống chịu lỗi Byzantine thiết thực)

Để ngăn ngừa các vấn đề trên, chúng ta cần các thuật toán khác, đảm bảo được tính hoàn thiện. Thuật toán BFT là một trong số đó, được lần đầu vào năm 1982 bởi Lamport, Shostak, Pease. Vào năm 1999, Miguel Castro và Barbara Liskov giới thiệu "Hệ thống chịu lỗi Byzantine thiết thực"() cung cấp tính năng nhân bản máy trạng thái hiệu suất cao.

Trong thuật toán PoW được nêu ở trên, mặc dù mỗi nút đều nhận và xác thực các khối, không có sự trao đổi thông báo giữa các nút để đạt được sự đồng thuận. Tuy nhiên, trong PBFT, mỗi nút đều giao tiếp với các nút tham gia khác để đạt được sự đồng thuận và tính hoàn thiện của khối cũng có thể được đảm bảo ngay khi các nút có thể đạt được sự đồng thuận.

Hoạt động giao tiếp giữa các nút về cơ bản diễn ra như sau. Tuy nhiên, có một số biến thể phản ánh đặc điểm của từng hệ thống.

Như đã nêu ở trên, về cơ bản, một nút tham gia trong PBFT giao tiếp với tất cả các nút trong mạng tại một số giai đoạn. Đặc tính này giới hạn số lượng nút vì khối lượng giao tiếp tăng theo cấp số nhân khi số lượng nút tăng lên.

Cơ chế đồng thuận trong Klaytn

Klaytn mong muốn trở thành một nền tảng lấy dịch vụ làm trọng tâm và sẵn sàng cho doanh nghiệp. Do đó, chúng ta cần giải quyết vấn đề về tính hoàn thiện đã nêu ở trên và mạng sẽ có thể cho phép nhiều nút tham gia vào mạng. Để thực hiện được điều này, Klaytn đang sử dụng phiên bản tối ưu hóa của Istanbul BFT, phiên bản này triển khai PBFT với một số sửa đổi để xử lý các đặc tính của mạng chuỗi khối.

Klaytn đạt được tính hoàn thiện nhanh nhờ việc áp dụng và cải thiện Istanbul BFT. Do việc xác thực và đồng thuận được thực hiện cho mỗi khối nên sẽ không phát sinh hiện tượng phân nhánh, đồng thời, tính hoàn thiện của khối được đảm bảo ngay lập tức sau khi đạt được sự đồng thuận.

Ngoài ra, vấn đề về việc tăng khối lượng giao tiếp trong thuật toán BFT cũng được giải quyết bằng cách sử dụng Ủy ban được chọn ngẫu nhiên. Các CN cùng nhau tạo thành một Hội đồng và với mỗi lần tạo khối, một phần trong số này được chọn làm thành viên của Ủy ban bằng cách sử dụng VRF (Chức năng ngẫu nhiên có thể xác minh).

Do các thông báo về đồng thuận chỉ được trao đổi giữa các thành viên ủy ban, nên khối lượng giao tiếp có thể bị giới hạn dưới mức thiết kế, mặc dù tổng số các CN tăng lên.

Hiện tại, mạng chính thức của Klaytn, Cypress, có thể cung cấp thông lượng cao ở mức 4000 giao dịch mỗi giây, với khoảng thời gian tạo khối là một giây. Hiện tại, hơn 50 nút đồng thuận có thể tham gia vào CNN (Mạng nút đồng thuận) và con số này sẽ liên tục tăng lên khi Klaytn tiếp tục tích cực tối ưu hóa thuật toán.

Trong Klaytn, có ba loại nút, CN (Nút đồng thuận), ON (Nút proxy) và EN (Nút điểm cuối). CN được quản lý bởi các CCO (Người vận hành Core Cell) và chịu trách nhiệm tạo khối. Các khối này được xác minh bởi tất cả các nút trong mạng. Vui lòng tham khảo để tìm hiểu thêm về mô hình cấu trúc mạng này.

Bitcoin
PoW
PoS
ra mắt
PBFT
Luồng thông báo của PBFT
Cấu trúc liên kết mạng
Khái niệm về hội đồng và ủy ban
ở đây