Đồng thuận mở rộng quy mô cho doanh nghiệp: Giải thích thuật toán IBFT

blog 1Tin tứcDevelopersEnterpriseBlockchain ExplainedEvents and ConferencePressBản tin

Theo dõi bản tin của chúng tôi.

Địa chỉ email

Chúng tôi tôn trọng quyền riêng tư của bạn

Trang chủBlogEnterprise Blockchain

Đồng thuận mở rộng quy mô cho doanh nghiệp: Giải thích thuật toán IBFT

Cách Istanbul Byzantine Fault Tolerance (IBFT) cải thiện tính cuối cùng và tăng thông lượng trong các mạng Ethereum riêng tư. Bởi ConsenSysJune 22, 2018Đăng vào ngày 22 tháng 6 năm 2018

Anh hùng Ethereum ConsenSys

Các thuật toán đồng thuận là một trong những đổi mới cốt lõi của blockchain, nhưng cũng là một trong những điều khó hiểu nhất. Satoshi Nakamoto đã tạo ra một phiên bản Proof of Work (PoW) được triển khai như một phương tiện để bảo mật và xác thực đồng thời các giao dịch Bitcoin. Cộng đồng blockchain đã xây dựng trên tầm nhìn cốt lõi đó để tạo ra một món súp bảng chữ cái của Proof of Stake (PoS), Proof of Authority (PoA), PBFT (Practical Byzantine Fault Tolerant) và nhiều thứ khác đều được thiết kế để xây dựng sự đồng thuận trong một hệ thống, tạo ra một nguồn chân lý duy nhất làm cho blockchain trở nên có giá trị.

IBFT (Istanbul Byzantine Fault Tolerant) là một cơ chế đồng thuận thay thế cho Proof of Work trong mạng Ethereum. Giống như các thuật toán khác, IBFT đảm bảo một thứ tự theo thỏa thuận duy nhất cho các giao dịch trong blockchain và cung cấp các lợi ích bổ sung cho doanh nghiệp, bao gồm cả tính hoàn thiện thanh toán. IBFT là lần đầu tiên được triển khai tại Geth bởi Amis Technologies, và ngay sau khi được triển khai trong Quorum.

Trước khi đi vào hoạt động của cơ chế đồng thuận IBFT, điều đáng nói là khi nào và tại sao một người muốn sử dụng IBFT. Trong một blockchain công khai, câu trả lời ngắn gọn là có thể bạn sẽ không. Nhưng khi nói đến tổ hợp hoặc blockchain riêng tư, IBFT bắt đầu trông khá hấp dẫn.

Thuật toán PoW nổi tiếng tốn kém cả về phần cứng và điện năng. Chi phí này là có chủ ý, để ngăn bất kỳ ai dễ dàng chiếm lấy mạng, và do đó PoW rất thích hợp cho các tình huống có toàn quyền phân quyền mà bất kỳ ai (kể cả những kẻ tấn công) đều có thể tham gia. Tuy nhiên, các nút trong chuỗi liên hợp / tư nhân được các doanh nghiệp sử dụng về bản chất được tin cậy hơn so với các mã trong chuỗi công khai. Do đó, cơ chế đồng thuận PoW có thể quá nặng nề và các cơ chế khác có thể cung cấp sự tin tưởng “đủ” để chạy một hệ thống phân tán.

Tương tự như vậy, Proof of Stake có thể ít liên quan hơn đối với các doanh nghiệp, bởi vì việc thanh toán cho khí đốt ít quan trọng hơn trong một mạng lưới được phép. Vì các nút không (nhất thiết) cần duy trì tiền tệ trong mạng, PoS sẽ đưa ra các yêu cầu không liên quan.

Xem xét những sự đánh đổi này, Proof of Authority (PoA) nổi lên như một giải pháp tốt nhất có thể, sử dụng một hệ thống theo đó các nút trong mạng được phân bổ đặc quyền sản xuất các khối mới cho chuỗi bằng cách sử dụng hệ thống vòng lặp hoặc hệ thống tùy ý khác.

IBFT là một trong nhiều hương vị của PoA và cung cấp các lợi ích sau:

  • Khối cuối cùng ngay lập tức. Chỉ có 1 khối được đề xuất ở độ cao chuỗi nhất định. Do đó, chuỗi đơn sẽ loại bỏ các khối phân nhánh, không chú ý và rủi ro rằng một giao dịch có thể được “hoàn tác” một lần trên chuỗi sau đó.
  • Giảm thời gian giữa các khối. Nỗ lực cần thiết để xây dựng và xác thực các khối được giảm đáng kể (đặc biệt đối với PoW), làm tăng đáng kể thông lượng của chuỗi.
  • Tính toàn vẹn dữ liệu cao và khả năng chịu lỗi. IBFT sử dụng một nhóm trình xác nhận để đảm bảo tính toàn vẹn của mỗi khối được đề xuất. Phần lớn (~ 66%) trong số các trình xác thực này được yêu cầu ký vào khối trước khi chèn vào chuỗi, khiến cho việc giả mạo khối trở nên rất khó khăn. ‘Quyền lãnh đạo’ của nhóm cũng thay đổi theo thời gian – đảm bảo một nút bị lỗi không thể gây ảnh hưởng lâu dài đến chuỗi.
  • Hoạt động linh hoạt. Nhóm trình xác thực có thể được sửa đổi kịp thời, đảm bảo nhóm chỉ chứa các nút được tin cậy đầy đủ.

Ở đây, chúng tôi đã cung cấp tổng quan về IBFT, chủ yếu là các thuật ngữ phi kỹ thuật. Đối với một số đề xuất ban đầu của IBFT, bạn có thể xem lại các EIP trên GitHub:

Trong phần còn lại của bài viết này, chúng tôi sẽ khám phá các cân nhắc kỹ thuật hơn của IBFT, thảo luận về nhiều khái niệm được tìm thấy trong EIP và chúng tôi đã học được thông qua nghiên cứu của riêng mình.


Lưu ý: Mã IBFT cũng có thể được tìm thấy trong một yêu cầu kéo go-ethereum # 16385.

Hoạt động

Cơ chế đồng thuận IBFT bao gồm các thành phần sau:

  1. A PBFT mô hình đồng thuận nhóm được truyền cảm hứng.
  2. Một quy trình mà các thành viên có thể được thêm vào / xóa khỏi nhóm xác thực.

IBFT yêu cầu Block Header phải được làm lại (một cách tinh vi) để hỗ trợ tất cả các khía cạnh của khả năng.

Mô hình đồng thuận nhóm

Tổng quat

IBFT sử dụng một nhóm các nút xác thực (Trình xác thực) hoạt động trên mạng Ethereum để xác định xem khối được đề xuất có phù hợp để bổ sung vào chuỗi hay không.

Một nút của Trình xác thực được chọn tùy ý làm Người đề xuất và chịu trách nhiệm xây dựng một khối ở khoảng thời gian khối và chia sẻ khối đó với nhóm. Nếu phần lớn Người xác thực coi khối là hợp lệ, nó sẽ được thêm vào blockchain.

Khi hoàn thành vòng đồng thuận, Người xác thực có thể chọn một Người đề xuất mới sẽ chịu trách nhiệm cung cấp Khối ứng cử viên vào khoảng thời gian khối tiếp theo.

Cơ chế đồng thuận là một máy trạng thái được đồng bộ hóa có trách nhiệm đảm bảo tất cả Trình xác thực nối cùng một khối vào chuỗi ở cùng độ cao.

Nếu một khối không thể chèn, Người đề xuất sẽ bị thay đổi và quá trình bắt đầu lại.

Để đảm bảo chỉ có một khối có thể được thêm vào máy trạng thái, IBFT ngăn việc thay đổi khối được đề xuất sau khi đa số người xác thực đã đồng ý với việc chèn khối đó (nhưng không thực hiện công việc đã nói), quá trình này được gọi là ‘Khóa khối’.

Cơ chế đồng thuận IBFT cung cấp sự ổn định của hệ thống với điều kiện ít hơn 1/3 số nút xác thực đang hoạt động không chính xác (do bị xâm nhập hoặc do mã bị lỗi). I E. để dung nạp F các nút bị lỗi, nhóm xác thực phải chứa ít nhất 3F + 1 nút (nhiều hơn điều này không làm tăng tính toàn vẹn của hệ thống).

Lưu ý: Ở đây F ngụ ý số lượng các nút bị lỗi được hệ thống dung nạp.

Máy trạng thái

Máy trạng thái IBFT

Những trạng thái
  • Đang chờ đề xuất. Trình xác thực đang đợi một khối mới được cung cấp bởi người đề xuất hiện tại. Nếu người xác nhận là người đề xuất cho vòng này, họ chuẩn bị khối được đề xuất và truyền nó trong một thông báo chuẩn bị trước.
  • Chuẩn bị. Đã nhận được một khối được đề xuất (hợp lệ) và đã thông báo cho trình xác nhận-ngang hàng; hiện đang đợi trình xác thực-ngang hàng thông báo về việc họ chấp nhận khối.
  • Sẵn sàng. Đã nhận được sự chấp nhận của trình xác thực-ngang hàng và đang chờ chúng ở vị trí tương tự. Ở giai đoạn này, khối được đề xuất đã bị ‘khóa’ và không thể thay thế cho đến khi tiến hành thử chèn.
  • Thay đổi vòng. Vòng đấu đã hết thời gian chờ trước khi đạt được sự đồng thuận hoặc không thể chèn khối. Chờ tất cả người xác nhận đồng ý về số vòng tiếp theo.
Chuyển tiếp
  1. Ađang chờ Đề xuất → Chuẩn bị. Khi nhận được một khối mới (thông báo Preprepare) từ người đề xuất (tức là khối hợp lệ trong nội dung của nó, cũng như điểm chèn chuỗi được đề xuất của nó).
  2. Đang chờ đề xuất → Vòng thay đổi. Đề xuất đã nhận không phải là một khối hợp lệ theo một bộ quy tắc nhất định (ví dụ: người đề xuất không hợp lệ, đánh số vòng không chính xác).
  3. Chuẩn bị → Sẵn sàng. Khi nhận được thông báo 2F + 1 (Chuẩn bị thông báo) từ các trình xác thực ngang hàng cho biết khối được đề xuất phù hợp để chèn.
  4. Sẵn sàng → Đang chờ đề xuất. Khi nhận được thông báo 2F + 1 (Thông báo cam kết) từ các trình xác thực ngang hàng cho biết họ đã sẵn sàng nối khối vào chuỗi. Khi chuyển đổi, quá trình gắn khối vào chuỗi được thực hiện (thành công).
  5. Sẵn sàng → Thay đổi vòng. Theo Sẵn sàng->Đang chờ đề xuất, tuy nhiên, việc chèn khối không thành công.
  6. Vòng thay đổi → Đang chờ đề xuất. 2F + 1 người xác nhận đồng ý về số vòng tiếp theo sẽ được sử dụng.

Lưu ý: Tất cả các chuyển đổi thành “RoundChange” dẫn đến việc Trình xác thực truyền thông báo “RoundChange” đến các trình xác thực cùng cấp của nó.

Khóa khối

IBFT yêu cầu không được tạo ra các fork. Để đạt được điều này, khi một khối đã được đa số đồng ý (tức là khi vào trạng thái Sẵn sàng), nó sẽ trở thành “bị khóa”.

Điều này có nghĩa là không có khối nào khác sẽ được xem xét để chèn cho đến khi nỗ lực thêm khối này vào chuỗi đã được thực hiện. Do đó, hoặc khối được chèn thành công (sau khi nhận đủ thông báo cam kết, trong vòng này hoặc các vòng tiếp theo), hoặc khối không chèn được, sẽ bị loại bỏ và một khối mới được đề xuất ở chiều cao chuỗi hiện tại.

Thành viên nhóm xác thực

Các thành viên của nhóm xác nhận có thể thay đổi theo thời gian thông qua cơ chế bỏ phiếu. Thành viên có thể được thêm hoặc bớt thông qua đa số (Tầng (N / 2) + 1) phiếu bầu; mỗi phiếu bầu được ghi lại trong Tiêu đề khối.

Mỗi nút trong mạng (bao gồm cả các nút không xác thực) chịu trách nhiệm theo dõi kiểm phiếu cho từng trình xác thực để xác định Trình xác thực hiện tại và đảm bảo chữ ký trên các khối đã khai thác nằm trong nhóm dự kiến.

Với mỗi phiếu bầu được chứa trong Tiêu đề khối, chỉ Người đề xuất cho một vòng nhất định mới có thể bỏ phiếu. Do đó, điều quan trọng là, nếu các nút được thêm / xóa kịp thời, thì vai trò Người đề xuất phải được cập nhật thường xuyên.

Khi một nút đạt được đa số phiếu bầu, họ ngay lập tức tham gia / rời khỏi nhóm trình xác thực.

IBFT công nhận Kỷ nguyên biểu quyết, xác định thời điểm mà tại đó tất cả các phiếu bầu chưa đạt đa số đều bị loại bỏ, buộc phải bắt đầu lại quá trình kiểm phiếu biểu quyết. Điều này ngụ ý khi kiểm đếm phiếu bầu, Người xác thực chỉ cần bắt đầu ở thời điểm gần đây nhất. Theo mặc định, Kỷ nguyên biểu quyết xảy ra sau mỗi 30.000 khối.

Các phiếu bầu xác định sự thay đổi trạng thái (tức là các ứng cử viên được bỏ phiếu, người xác nhận được bỏ phiếu), không bỏ phiếu cho một nút nhất định ngụ ý Người xác thực không muốn nút đó thay đổi trạng thái (không cần bỏ phiếu rõ ràng để duy trì hiện trạng).

Trình tái cấu trúc tiêu đề khối

Để hỗ trợ IBFT trong Ethereum, một số thay đổi phải được thực hiện đối với tiêu đề khối. Những thay đổi này bao gồm:

  • người thụ hưởng: xác định nút đang bỏ phiếu.
  • nonce: chỉ định “hướng” bỏ phiếu – AUTH hoặc DROP.
  • mixHash: số ma thuật được cố định, xác định khối này đang được xác thực IBFT.
  • ommersHash: phải là băm của một tập hợp trống, vì không có khối ommer khi hoạt động dưới IBFT.
  • dấu thời gian: ít nhất phải là dấu thời gian của khối mẹ + khoảng thời gian của khối.
  • độ khó: phải được điền bằng 0x0000000000000001.
  • extraData: chứa dữ liệu cụ thể của IBFT bao gồm Danh sách địa chỉ trình xác thực, ProposerSeal (xác định người đề xuất), committingSeals (danh sách các trình xác thực đã báo cáo ‘cam kết’ trên khối này).

Vì danh sách các committingSeals cho mỗi trình xác thực là (có thể) khác nhau, điều quan trọng là khối băm không được bao gồm thông tin này – tức là mặc dù hai khối có các trường committingSeals khác nhau, chúng đại diện cho cùng một thông tin (tức là các giao dịch, v.v. giống hệt nhau).

Phần kết luận

Tóm lại, IBFT là một giải pháp chịu lỗi của Byzantine cung cấp khả năng hoàn thiện giao dịch ngay lập tức, làm giảm cơ sở hạ tầng cần thiết mà PoW yêu cầu.

Mặc dù không bao giờ được sử dụng trên mạng chính Ethereum (với nhiều thành phần tham gia rộng hơn, không xác định), nhưng nó mang lại lợi ích đáng kể khi được sử dụng trên một chuỗi riêng tư nơi nhóm xác thực được tin cậy và chịu trách nhiệm; nó cung cấp một giải pháp lý tưởng cho một chuỗi có nhịp cố định và tốc độ xử lý giao dịch có thể dự đoán được.

Các quy trình được khám phá trong bài viết này cung cấp sự tin tưởng rằng một mạng sử dụng IBFT sẽ chịu đựng được các nút Byzantine và có thể được phục hồi nếu các nút đó được xem là thực hiện quyền kiểm soát trên mạng.

Bản tin Đăng ký nhận bản tin của chúng tôi để biết tin tức mới nhất về Ethereum, các giải pháp doanh nghiệp, tài nguyên dành cho nhà phát triển và hơn thế nữa.Hướng dẫn hoàn chỉnh về mạng kinh doanh chuỗi khốiHướng dẫn

Hướng dẫn hoàn chỉnh về mạng kinh doanh chuỗi khối

Giới thiệu về TokenizationHội thảo trên web

Giới thiệu về Tokenization

Tương lai của tài sản kỹ thuật số tài chính và DeFiHội thảo trên web

Tương lai của tài chính: Tài sản kỹ thuật số và DeFi

Ethereum doanh nghiệp là gìHội thảo trên web

Ethereum doanh nghiệp là gì?

Ngân hàng Trung ương và Tương lai của Tiền tệGiấy trắng

Ngân hàng Trung ương và Tương lai của Tiền tệ

Komgo Blockchain cho Tài trợ Thương mại Hàng hóaCase Stud

Komgo: Blockchain cho Tài trợ Thương mại Hàng hóa

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Like this post? Please share to your friends:
Adblock
detector
map