BEP-341: Validators can produce consecutive blocks #341

NathanBSC · 2024-01-12T13:36:19Z

  BEP: 341
  Title: Validators can produce consecutive blocks
  Status: Draft
  Type: Standards
  Created: 2023-09-27
  Discussions(optional): https://forum.bnbchain.org/t/bep-idea-validators-can-produce-consecutive-blocks/2052

BEP-341: Validators can produce consecutive blocks

BEP-341: Validators can produce consecutive blocks

1. Summary

Each epoch in BSC consists of multiple slots, and a batch of validators take turns in a predefined order to obtain priority block-producing rights for each slot. This BEP proposes an adjustment to the allocation of priority block-producing rights: each validator receives priority block-producing rights for a predetermined number of consecutive slots per round.

2. Abstract

BEP-341 describes a new allocation method for priority block-producing rights, which is logically concise and significantly enhances the system's transaction processing capacity, while remaining orthogonal to transaction processing optimization techniques within blocks.

3. Motivation

The BSC ecosystem is active and continuously evolving, requiring ongoing improvements to the system's transaction processing capacity.

4. Specification

4.1 Scaling Principle

Currently, each validator obtains priority block-producing rights for a single slot and is then rotated, with a fixed block interval of t. The transaction processing limit is t/2 for validating transactions from the previous block and t/2 for processing transactions in the new block.

Assuming the number of transactions that can be processed is T, the average TPS is calculated as follows:

After implementing this BEP, each validator can obtain priority block-producing rights for a continuous sequence of n slots in one round. The first block they process still allocates t/2 for validating transactions from the previous block and t/2 for processing transactions in the new block. However, subsequent blocks can skip the transaction validation process and focus on processing transactions in the new block. It is recommended that the processing time for the last block in their current round be only half of the time required to process transactions in the new block. This helps avoid the situation where the first block processed by the next validator is close to being an empty block.

The TPS after continuous block production is as follows:

Therefore, the TPS improvement rate is:

The relationship between the number of continuous blocks produced and TPS improvement is

As shown in the graph, it is evident that continuous block production cannot double the TPS. There is no benefit when n<3, and increasing n beyond 5 does not proportionally increase the benefits. Therefore, a value within the range [3, 5] is suitable for n; when n=4, r=50%.

4.2 Implementation Specification

4.2.1 Priority Allocation

Each epoch predefines a set of validators, with a total of validatorN validators, and each validator within the set has a unique index ranging from [0, validatorN). If the current block height is blockN, then the validators with the following indices obtain priority block-producing rights.

4.2.2 Validator Set Switch

Each epoch will choose a new validator set, assuming an epoch contains epochSlots slots. The validator set switch occurs only when the block height reaches Bswitch to prevent epoch block forging. The calculation of Bswitch is as follows:

4.2.3 Block Avoidance

To prevent fewer than 1/2 of the nodes from controlling the entire network, block producers are required to produce fewer than n blocks within the previous ((validatorN/2+1)*n-1) historical blocks.

4.2.4 Governable Number of Consecutive Blocks

When n=1, it is equivalent to disabling the feature of consecutive block production, while significant optimization is observed when n belongs to the range [3,5]. Currently, the range for the value of n is set to [1,9] but except 2.

The initial value of n is 1, and changing its value requires the BSC governance process.

4.2.5 Combatting MEV

As the consecutive period in which a single validator gains priority in block production extends, it may facilitate MEV extraction, potentially leading validators to include more transactions in the later blocks they consecutively produce. To constrain validators to promptly package transactions, within a validator's consecutive priority over n blocks, the transaction fees' split to the SystemRewardContract will increase linearly with block number, capped at the value denoted as systemRewardAntiMEVRatio.
Respectively, the split ratio remains at systemRewardBaseRatio when continuous block production is disabled. Once continuous block production is enabled (i.e., when n > 1), the systemRewardRatio is calculated as:

as shown in the following picture:

The initial value of systemRewardAntiMEVRatio is 0, and changing its value also requires the BSC governance process.

5. Incentive Fairness Analysis

Within a single epoch, tail validators have fewer block-producing opportunities, but the allocation of priority rights is unbiased and cannot be manipulated. Therefore, from a statistical perspective, it is fair.

If a validator tries to extract more MEV by placing more transactions in later blocks they produce, it will also increase user transaction confirmation times. To curb this, the systemRewardAntiMEVRatio can be raised through the governance process, which will increase the proportion of transaction fees allocated to the SystemRewardContract. These bonuses will be distributed as Fast Finality voting rewards to validators, keeping their overall benefits unchanged. However, during high traffic and transaction backlog, high-performance validators usually handle more transactions. These changes will reduce the income advantage of having high performance.

6. Security Analysis

This BEP relies on BSC's Fast Finality feature. If Fast Finality fails, it may result in the following issues:

Nodes intentionally hide mined blocks, potentially leading to longer short-term reorganizations.
The probability of finality for transactions increases, requiring waiting for 2/3*validatorN*n+ blocks.

7. Liveness Analysis

The liveness of the chain remains unchanged, meaning it is required to ensure that at least (validatorN/2+1) validators are active. The proof is as follows:

If (validatorN/2+1) validators are active and none are allowed to produce blocks at a certain moment, each validator must have produced at least n blocks in the past ((validatorN/2+1)*n-1) blocks. Thus, collectively, at least (validatorN/2+1)*n blocks must have been produced, which is impossible. Therefore, at any moment, at least one of the (validatorN/2+1) validators must be allowed to produce blocks.

8. License

The content is licensed under CC0.

Magkoohp · 2024-01-13T03:53:25Z

0x4ea83aebbd3d2c29cfe79737aa35b4302f26bcb6

BEPs/BEP-341.md

huihzhao · 2024-06-12T08:15:59Z

any APY impact for validators?

buddh0 · 2024-06-12T10:41:13Z

Incentive Fairness Analysis

pls refer 5. Incentive Fairness Analysis

thy-r · 2024-06-19T07:07:38Z

Regarding 4.2.5 Combatting MEV, the BEP says "To constrain validators to promptly package transactions, within a validator's consecutive priority over n blocks, the transaction fees' split to the SystemRewardContract will increase linearly with block number... "

The problem with this approach is that it is not possible to force validators to share their MEV profit with delegators / SystemRewardContract.

So, if for example the validators make an extra MEV profit by producing consecutive blocks, they can keep this extra profit to themselves, bypassing SystemRewardContract. Therefore, the constraint made by systemRewardAntiMEVRatio is not really effective as it is limited only to the transaction fees, which is likely just a small fraction of the total profit that validators could potentially make by signing consecutive blocks.

The bottom line is that the extra profit from signing consecutive blocks is much higher than the validator profit from transaction fees and therefore validators can ignore the constraint made by systemRewardAntiMEVRatio and users will wait longer for transaction confirmations.

This change is definitely good for the validators, who will be able to aggressively extract more MEV by signing consequent blocks, but it is not clear how this change is good for the network, as it will result in lower confirmation time for the users.

huihzhao · 2024-06-19T12:38:43Z

Regarding 4.2.5 Combatting MEV, the BEP says "To constrain validators to promptly package transactions, within a validator's consecutive priority over n blocks, the transaction fees' split to the SystemRewardContract will increase linearly with block number... "

The problem with this approach is that it is not possible to force validators to share their MEV profit with delegators / SystemRewardContract.

So, if for example the validators make an extra MEV profit by producing consecutive blocks, they can keep this extra profit to themselves, bypassing SystemRewardContract. Therefore, the constraint made by systemRewardAntiMEVRatio is not really effective as it is limited only to the transaction fees, which is likely just a small fraction of the total profit that validators could potentially make by signing consecutive blocks.

The bottom line is that the extra profit from signing consecutive blocks is much higher than the validator profit from transaction fees and therefore validators can ignore the constraint made by systemRewardAntiMEVRatio and users will wait longer for transaction confirmations.

This change is definitely good for the validators, who will be able to aggressively extract more MEV by signing consequent blocks, but it is not clear how this change is good for the network, as it will result in lower confirmation time for the users.

As BNBChain has impelmented the PBS, the MEV revenue that through the standard builder API could be included in the gas fee. that is another consideration when wen discuss this topic. I assume, for normal users, they can also use a builder to be protected from attacks, and also of course for searchers.

NathanBSC · 2024-07-25T10:27:34Z

rebase master and force push 07.25

Mofidzol

BEPs/BEP-341.md
README.md
منوی ناوبری

کد
مسائل
8
BEP-341: اعتبار سنجی ها می توانند بلوک های متوالی تولید کنند #341
ادغام شد
zzzckck 12 تعهد را ادغام کرد bnb-chain:استاد از NathanBSC:bep-234-validators-can-production-consecutive-blocks در 29 ژوئیه 2024
گفتگو 14
متعهد می شود 12
چک ها 0
فایل ها تغییر کردند 13
فیلتر فایل

120 تغییر: 120 اضافه و 0 حذف120
BEPs/BEP-341.md
Copied!
شماره خط فایل اصلی شماره خط تفاوت تغییر خط تفاوت
@@ -0،0 +1120 @@
< پیش >
BEP: 341
عنوان: اعتبار سنجی ها می توانند بلوک های متوالی تولید کنند
وضعیت: پیش نویس
نوع: استاندارد
ایجاد: 27/09/2023
بحث‌ها (اختیاری): https://forum.bnbchain.org/t/bep-idea-validators-can-produce-consecutive-blocks/2052
</ pre >

BEP-341: اعتبار سنجی ها می توانند بلوک های متوالی تولید کنند

[ BEP-341: اعتبار سنجی ها می توانند بلوک های متوالی تولید کنند ] ( #bep-341-validators-can-produce-consecutive-blocks )
[ 1. خلاصه ] ( Add BEP1&2 proposals #1-خلاصه )
[ 2. چکیده ] ( Edit index on BEP2 #2-چکیده )
[ 3. انگیزه ] ( BEP3: Add HTLC #3-انگیزه )
[ 4. مشخصات ] ( BEP4: 256-bit Tokens #4-مشخصات )
- [ 4.1 اصل مقیاس‌بندی ] ( Whitelist Script for BEP12 #41-scaling-principle )
- [ 4.2 Implementation Specification ] ( Register TrustToken Source #42-implementation-specification )
- [ 4.2.1 تخصیص اولویت ] ( Trust wallet #421-priority-allocation )
- [ 4.2.2 سوئیچ تنظیم اعتبار ] ( Trust wallet #422-validator-set-switch )
- [ 4.2.3 Block Avoidance ] ( Trust wallet #423-block-avoidance )
- [ 4.2.4 تعداد بلوک های متوالی قابل اداره ] ( Bttc #424-governable-number-of-consecutive-blocks )
- [ 4.2.5 Combatting MEV ] ( BEP-425: Hint based Parallel Transaction Execution #425-combatting-mev )
[ 5. تحلیل انصاف انگیزشی ] ( BEP-5: Token Resources [IMPROVEMENT] #5-انگیزه-انصاف-تحلیل )
[ 6. تجزیه و تحلیل امنیتی ] ( BEP-6: Add delist proposal #6-security-analysis )
[ 7. تجزیه و تحلیل Liveness ] ( BEP 7: Bring Non-fungible Tokens(NFTs) to Binance Chain and expand the use cases. #7-liveness-analysis )
[ 8. مجوز ] ( Fix BEP2 markdown style. #8-مجوز )

1. خلاصه

هر دوره در BSC از چندین اسلات تشکیل شده است و دسته ای از اعتبار سنجی ها به نوبت به ترتیب از پیش تعریف شده برای به دست آوردن حقوق اولویت تولید بلوک برای هر شکاف به کار می روند. این BEP تنظیمی را برای تخصیص حقوق تولید بلوک اولویتی پیشنهاد می کند: هر اعتبارسنجی حقوق تولید بلوک اولویت را برای تعداد از پیش تعیین شده اسلات های متوالی در هر دور دریافت می کند.

2. چکیده

BEP-341 یک روش تخصیص جدید برای حقوق تولید بلوک اولویتی را توصیف می کند، که از نظر منطقی مختصر است و ظرفیت پردازش تراکنش سیستم را به طور قابل توجهی افزایش می دهد، در حالی که متعامد به تکنیک های بهینه سازی پردازش تراکنش در داخل بلوک ها باقی می ماند.

3. انگیزه

اکوسیستم BSC فعال و پیوسته در حال تکامل است و به بهبود مستمر ظرفیت پردازش تراکنش سیستم نیاز دارد.

4. مشخصات

4.1 اصل مقیاس بندی

در حال حاضر، هر اعتبارسنجی حق تولید بلوک اولویت را برای یک شکاف به دست می‌آورد و سپس با فاصله بلوک ثابت t می‌چرخد. حد پردازش تراکنش t/2 برای اعتبارسنجی تراکنش های بلوک قبلی و t/2 برای پردازش تراکنش ها در بلوک جدید است.
< div align = " center " >
<img src=./assets/bep-341/4.1-1.png عرض=60% />
</ div >
با فرض اینکه تعداد تراکنش های قابل پردازش T باشد، میانگین TPS به صورت زیر محاسبه می شود:
< div align = " center " >
<img src=./assets/bep-341/4.1-2.png عرض=18% />
</ div >
پس از اجرای این BEP، هر اعتبارسنجی می‌تواند حقوق تولید بلوک اولویت را برای یک دنباله پیوسته از n اسلات در یک دور بدست آورد. اولین بلوکی که آنها پردازش می کنند هنوز t/2 را برای اعتبارسنجی تراکنش های بلوک قبلی و t/2 را برای پردازش تراکنش ها در بلوک جدید اختصاص می دهد. با این حال، بلوک‌های بعدی می‌توانند فرآیند اعتبارسنجی تراکنش را نادیده بگیرند و روی پردازش تراکنش‌ها در بلوک جدید تمرکز کنند. توصیه می‌شود که زمان پردازش آخرین بلوک در دور فعلی فقط نیمی از زمان مورد نیاز برای پردازش تراکنش‌ها در بلوک جدید باشد. این به جلوگیری از موقعیتی کمک می کند که اولین بلوک پردازش شده توسط اعتبارسنجی بعدی نزدیک به یک بلوک خالی باشد.
< div align = " center " >
<img src=./assets/bep-341/4.1-3.png عرض=60% />
</ div >
TPS پس از تولید بلوک پیوسته به شرح زیر است:
< div align = " center " >
<img src=./assets/bep-341/4.1-4.png عرض=50% />
</ div >
بنابراین، نرخ بهبود TPS:
< div align = " center " >
<img src=./assets/bep-341/4.1-5.png عرض=40% />
</ div >
رابطه بین تعداد بلوک های پیوسته تولید شده و بهبود TPS وجود دارد
< div align = " center " >
<img src=./assets/bep-341/4.1-6.png عرض=60% />
</ div >
همانطور که در نمودار نشان داده شده است، واضح است که تولید بلاک پیوسته نمی تواند TPS را دو برابر کند. وقتی n<3 فایده ای ندارد، و افزایش n بیش از 5 به طور متناسبی مزایا را افزایش نمی دهد. بنابراین، مقداری در محدوده [ 3، 5 ] برای n مناسب است. زمانی که n=4، r=50%.

4.2 مشخصات پیاده سازی

4.2.1 تخصیص اولویت

هر دوره مجموعه‌ای از اعتبار‌دهنده‌ها را از پیش تعریف می‌کند، با مجموع اعتبار‌دهنده‌های validatorN، و هر اعتبارسنجی درون مجموعه دارای یک شاخص منحصربه‌فرد در محدوده [ 0، validatorN) است. اگر ارتفاع بلوک فعلی blockN باشد، اعتبارسنجی‌هایی که شاخص‌های زیر را دارند، حقوق اولویت تولید بلوک را به دست می‌آورند.
buddh0 این گفتگو را به عنوان حل شده علامت گذاری کرد.
< div align = " center " >
<img src=./assets/bep-341/4.2.1.png عرض=36% />
</ div >

4.2.2 سوئیچ مجموعه اعتبار سنجی

هر دوره یک مجموعه اعتبار سنجی جدید را انتخاب می کند، با این فرض که یک دوره حاوی اسلات های epochSlots است. سوئیچ تنظیم اعتبار سنج فقط زمانی رخ می دهد که ارتفاع بلوک به Bswitch برسد تا از جعل بلوک دوره ای جلوگیری شود. محاسبه Bswitch به شرح زیر است:
< div align = " center " >
<img src=./assets/bep-341/4.2.2.png عرض=56% />
</ div >

4.2.3 اجتناب از بلوک

برای جلوگیری از کنترل کمتر از 1/2 گره ها بر کل شبکه، تولیدکنندگان بلوک باید کمتر از n بلوک را در بلوک های تاریخی قبلی ((validatorN/2+1) * n-1) تولید کنند.

4.2.4 تعداد بلوک های متوالی قابل اداره

وقتی n=1، معادل غیرفعال کردن ویژگی تولید بلوک های متوالی است، در حالی که بهینه سازی قابل توجهی مشاهده می شود که n به محدوده [ 3،5 ] تعلق دارد . در حال حاضر، محدوده برای مقدار n بر روی [ 1،9 ] تنظیم شده است اما به جز 2.

مقدار اولیه n 1 است و تغییر مقدار آن نیازمند فرآیند حاکمیت BSC است.

4.2.5 مبارزه با MEV

NathanBSC این گفتگو را به عنوان حل شده علامت گذاری کرد.
از آنجایی که دوره متوالی که در آن یک اعتبارسنجی منفرد در تولید بلوک اولویت پیدا می‌کند، ممکن است استخراج MEV را تسهیل کند، و به طور بالقوه اعتبارسنجی‌ها را به گنجاندن تراکنش‌های بیشتری در بلوک‌های بعدی که متوالی تولید می‌کنند، سوق می‌دهد. برای محدود کردن اعتبارسنجی‌ها به بسته‌بندی سریع تراکنش‌ها، در اولویت‌های متوالی اعتبارسنجی نسبت به n بلوک، تقسیم کارمزد تراکنش به SystemRewardContract به صورت خطی با شماره بلوک افزایش می‌یابد که با مقدار نشان داده شده به عنوان systemRewardAntiMEVRatio محدود می‌شود.
به ترتیب، نسبت تقسیم در systemRewardBaseRatio باقی می‌ماند که تولید بلوک پیوسته غیرفعال باشد. هنگامی که تولید بلوک پیوسته فعال می شود (یعنی زمانی که n> 1 باشد)، نسبت systemReward به صورت زیر محاسبه می شود:
< div align = " center " >
<img src=./assets/bep-341/4.2.5-1.png عرض=150% />
</ div >
همانطور که در تصویر زیر نشان داده شده است:
< div align = " center " >
<img src=./assets/bep-341/4.2.5-2.png عرض=75% />
</ div >

مقدار اولیه systemRewardAntiMEVRatio 0 است و تغییر مقدار آن به فرآیند حاکمیت BSC نیز نیاز دارد.

5. تجزیه و تحلیل انصاف انگیزه

در یک دوره واحد، اعتبارسنجی‌های دم فرصت‌های تولید بلوک کمتری دارند، اما تخصیص حقوق اولویت بی‌طرفانه است و نمی‌توان آن را دستکاری کرد. بنابراین از منظر آماری منصفانه است.

اگر یک اعتبارسنجی سعی کند MEV بیشتری را با قرار دادن تراکنش های بیشتر در بلوک های بعدی که تولید می کند استخراج کند، زمان تأیید تراکنش کاربر را نیز افزایش می دهد. برای مهار این امر، SystemRewardAntiMEVRatio را می توان از طریق فرآیند حاکمیت افزایش داد، که باعث افزایش نسبت کارمزد تراکنش تخصیص یافته به SystemRewardContract می شود. این پاداش‌ها به‌عنوان جوایز رای‌گیری Fast Finality بین اعتبارسنجی‌کنندگان توزیع می‌شود و مزایای کلی آن‌ها بدون تغییر باقی می‌ماند. با این حال، در طول ترافیک بالا و عقب ماندگی تراکنش ها، اعتبار سنجی های با عملکرد بالا معمولا تراکنش های بیشتری را انجام می دهند. این تغییرات مزیت درآمدی داشتن عملکرد بالا را کاهش خواهد داد.

6. تجزیه و تحلیل امنیتی

این BEP بر ویژگی Fast Finality BSC متکی است. اگر Fast Finality ناموفق باشد، ممکن است منجر به مشکلات زیر شود:
1 . گره ها عمداً بلوک های استخراج شده را پنهان می کنند و به طور بالقوه منجر به سازماندهی مجدد کوتاه مدت طولانی تر می شوند.
2 . احتمال نهایی شدن تراکنش ها افزایش می یابد و نیاز به انتظار برای 2/3 * validatorN * n+ بلوک است.

7. تجزیه و تحلیل Liveness

زنده بودن زنجیره بدون تغییر باقی می ماند، به این معنی که باید اطمینان حاصل شود که حداقل اعتبار سنجی (validatorN/2+1) فعال هستند. اثبات به شرح زیر است:

اگر اعتبار سنجی (validatorN/2+1) فعال باشد و هیچ کدام مجاز به تولید بلوک در یک لحظه خاص نباشد، هر اعتبارسنجی باید حداقل n بلوک در بلوک های گذشته ((validatorN/2+1) * n-1) تولید کرده باشد. . بنابراین، در مجموع، حداقل (validatorN/2+1) * n بلوک باید تولید شده باشد که غیرممکن است. بنابراین، در هر لحظه، حداقل یکی از اعتبار سنجی (validatorN/2+1) باید اجازه تولید بلوک را داشته باشد.

8. مجوز

محتوا تحت مجوز [ CC0 ] ( https://creativecommons.org/publicdomain/zero/1.0/ ) است .
فایل باینری اضافه شدBIN +40.4 کیلوبایت
BEPs/assets/bep-341/4.1-1.png
در حال بارگذاری
فایل باینری اضافه شدBIN + 12.4 کیلوبایت
BEPs/assets/bep-341/4.1-2.png
در حال بارگذاری
فایل باینری اضافه شدBIN +41.6 کیلوبایت
BEPs/assets/bep-341/4.1-3.png
در حال بارگذاری
فایل باینری اضافه شدBIN +31.8 کیلوبایت
BEPs/assets/bep-341/4.1-4.png
در حال بارگذاری
فایل باینری اضافه شدBIN + 25.8 کیلوبایت
BEPs/assets/bep-341/4.1-5.png
در حال بارگذاری
فایل باینری اضافه شدBIN + 29.6 کیلوبایت
BEPs/assets/bep-341/4.1-6.png
در حال بارگذاری
فایل باینری اضافه شدBIN +28 کیلوبایت
BEPs/assets/bep-341/4.2.1.png
در حال بارگذاری
فایل باینری اضافه شدBIN +37 کیلوبایت
BEPs/assets/bep-341/4.2.2.png
در حال بارگذاری
فایل باینری اضافه شدBIN +33.1 کیلوبایت
BEPs/assets/bep-341/4.2.3.png
در حال بارگذاری
فایل باینری اضافه شدBIN +67.6 KB
BEPs/assets/bep-341/4.2.5-1.png
در حال بارگذاری
فایل باینری اضافه شدBIN +419 کیلوبایت
BEPs/assets/bep-341/4.2.5-2.png
در حال بارگذاری
3 تغییر: 2 اضافه و 1 حذف3
README.md
Copied!
شماره خط فایل اصلی شماره خط تفاوت تغییر خط تفاوت
@@ -62,9 +62,10 @@ لیست موضوعات BEP در اینجا آمده است:
| [ BEP-322 ] ( ./BEPs/BEP322.md ) | مشخصات API Builder برای BNB Smart Chain | استانداردها | فعال |
| [ BEP-323 ] ( ./BEPs/BEP323.md ) | قالب بسته برای گرینفیلد | استانداردها | فعال |
| [ BEP-333 ] ( ./BEPs/BEP333.md ) | BNB Chain Fusion | استانداردها | فعال |
| [ BEP-334 ] ( ./BEPs/BEP-334.md ) | ماژول مجوز Greenfield CrossChain | استانداردها | پیش نویس |
| [ BEP-334 ] ( ./BEPs/BEP-334.md ) | ماژول مجوز Greenfield CrossChain | استانداردها | فعال |
| [ BEP-335 ] ( ./BEPs/BEP-335.md ) | خروج از ارائه دهنده ذخیره سازی ساده گرینفیلد | استانداردها | فعال |
| [ BEP-336 ] ( ./BEPs/BEP-336.md ) | پیاده سازی EIP-4844: Shard Blob Transactions | استانداردها | فعال |
| [ BEP-341 ] ( ./BEPs/BEP-341.md ) | اعتبار سنجی ها می توانند بلوک های متوالی | استانداردها | نامزد |
| [ BEP-342 ] ( ./BEPs/BEP-342.md ) | پیاده سازی EIP-5656: MCOPY | استانداردها | فعال |
| [ BEP-343 ] ( ./BEPs/BEP-343.md ) | پیاده سازی EIP-1153: Opcodes ذخیره سازی گذرا | استانداردها | فعال |
| [ BEP-344 ] ( ./BEPs/BEP-344.md ) | پیاده سازی EIP-6780: SELFDESTRUCT فقط در همان تراکنش | استانداردها | فعال

120 تغییر: 120 اضافه و 0 حذف120
BEPs/BEP-341.md
Copied!
شماره خط فایل اصلی شماره خط تفاوت تغییر خط تفاوت
@@ -0،0 +1120 @@
< پیش >
BEP: 341
عنوان: اعتبار سنجی ها می توانند بلوک های متوالی تولید کنند
وضعیت: پیش نویس
نوع: استاندارد
ایجاد: 27/09/2023
بحث‌ها (اختیاری): https://forum.bnbchain.org/t/bep-idea-validators-can-produce-consecutive-blocks/2052
</ pre >

BEP-341: اعتبار سنجی ها می توانند بلوک های متوالی تولید کنند

[ BEP-341: اعتبار سنجی ها می توانند بلوک های متوالی تولید کنند ] ( #bep-341-validators-can-produce-consecutive-blocks )
[ 1. خلاصه ] ( Add BEP1&2 proposals #1-خلاصه )
[ 2. چکیده ] ( Edit index on BEP2 #2-چکیده )
[ 3. انگیزه ] ( BEP3: Add HTLC #3-انگیزه )
[ 4. مشخصات ] ( BEP4: 256-bit Tokens #4-مشخصات )
- [ 4.1 اصل مقیاس‌بندی ] ( Whitelist Script for BEP12 #41-scaling-principle )
- [ 4.2 Implementation Specification ] ( Register TrustToken Source #42-implementation-specification )
- [ 4.2.1 تخصیص اولویت ] ( Trust wallet #421-priority-allocation )
- [ 4.2.2 سوئیچ تنظیم اعتبار ] ( Trust wallet #422-validator-set-switch )
- [ 4.2.3 Block Avoidance ] ( Trust wallet #423-block-avoidance )
- [ 4.2.4 تعداد بلوک های متوالی قابل اداره ] ( Bttc #424-governable-number-of-consecutive-blocks )
- [ 4.2.5 Combatting MEV ] ( BEP-425: Hint based Parallel Transaction Execution #425-combatting-mev )
[ 5. تحلیل انصاف انگیزشی ] ( BEP-5: Token Resources [IMPROVEMENT] #5-انگیزه-انصاف-تحلیل )
[ 6. تجزیه و تحلیل امنیتی ] ( BEP-6: Add delist proposal #6-security-analysis )
[ 7. تجزیه و تحلیل Liveness ] ( BEP 7: Bring Non-fungible Tokens(NFTs) to Binance Chain and expand the use cases. #7-liveness-analysis )
[ 8. مجوز ] ( Fix BEP2 markdown style. #8-مجوز )

1. خلاصه

هر دوره در BSC از چندین اسلات تشکیل شده است و دسته ای از اعتبار سنجی ها به نوبت به ترتیب از پیش تعریف شده برای به دست آوردن حقوق اولویت تولید بلوک برای هر شکاف به کار می روند. این BEP تنظیمی را برای تخصیص حقوق تولید بلوک اولویتی پیشنهاد می کند: هر اعتبارسنجی حقوق تولید بلوک اولویت را برای تعداد از پیش تعیین شده اسلات های متوالی در هر دور دریافت می کند.

2. چکیده

BEP-341 یک روش تخصیص جدید برای حقوق تولید بلوک اولویتی را توصیف می کند، که از نظر منطقی مختصر است و ظرفیت پردازش تراکنش سیستم را به طور قابل توجهی افزایش می دهد، در حالی که متعامد به تکنیک های بهینه سازی پردازش تراکنش در داخل بلوک ها باقی می ماند.

3. انگیزه

اکوسیستم BSC فعال و پیوسته در حال تکامل است و به بهبود مستمر ظرفیت پردازش تراکنش سیستم نیاز دارد.

4. مشخصات

4.1 اصل مقیاس بندی

در حال حاضر، هر اعتبارسنجی حق تولید بلوک اولویت را برای یک شکاف به دست می‌آورد و سپس با فاصله بلوک ثابت t می‌چرخد. حد پردازش تراکنش t/2 برای اعتبارسنجی تراکنش های بلوک قبلی و t/2 برای پردازش تراکنش ها در بلوک جدید است.
< div align = " center " >
<img src=./assets/bep-341/4.1-1.png عرض=60% />
</ div >
با فرض اینکه تعداد تراکنش های قابل پردازش T باشد، میانگین TPS به صورت زیر محاسبه می شود:
< div align = " center " >
<img src=./assets/bep-341/4.1-2.png عرض=18% />
</ div >
پس از اجرای این BEP، هر اعتبارسنجی می‌تواند حقوق تولید بلوک اولویت را برای یک دنباله پیوسته از n اسلات در یک دور بدست آورد. اولین بلوکی که آنها پردازش می کنند هنوز t/2 را برای اعتبارسنجی تراکنش های بلوک قبلی و t/2 را برای پردازش تراکنش ها در بلوک جدید اختصاص می دهد. با این حال، بلوک‌های بعدی می‌توانند فرآیند اعتبارسنجی تراکنش را نادیده بگیرند و روی پردازش تراکنش‌ها در بلوک جدید تمرکز کنند. توصیه می‌شود که زمان پردازش آخرین بلوک در دور فعلی فقط نیمی از زمان مورد نیاز برای پردازش تراکنش‌ها در بلوک جدید باشد. این به جلوگیری از موقعیتی کمک می کند که اولین بلوک پردازش شده توسط اعتبارسنجی بعدی نزدیک به یک بلوک خالی باشد.
< div align = " center " >
<img src=./assets/bep-341/4.1-3.png عرض=60% />
</ div >
TPS پس از تولید بلوک پیوسته به شرح زیر است:
< div align = " center " >
<img src=./assets/bep-341/4.1-4.png عرض=50% />
</ div >
بنابراین، نرخ بهبود TPS:
< div align = " center " >
<img src=./assets/bep-341/4.1-5.png عرض=40% />
</ div >
رابطه بین تعداد بلوک های پیوسته تولید شده و بهبود TPS وجود دارد
< div align = " center " >
<img src=./assets/bep-341/4.1-6.png عرض=60% />
</ div >
همانطور که در نمودار نشان داده شده است، واضح است که تولید بلاک پیوسته نمی تواند TPS را دو برابر کند. وقتی n<3 فایده ای ندارد، و افزایش n بیش از 5 به طور متناسبی مزایا را افزایش نمی دهد. بنابراین، مقداری در محدوده [ 3، 5 ] برای n مناسب است. زمانی که n=4، r=50%.

4.2 مشخصات پیاده سازی

4.2.1 تخصیص اولویت

هر دوره مجموعه‌ای از اعتبار‌دهنده‌ها را از پیش تعریف می‌کند، با مجموع اعتبار‌دهنده‌های validatorN، و هر اعتبارسنجی درون مجموعه دارای یک شاخص منحصربه‌فرد در محدوده [ 0، validatorN) است. اگر ارتفاع بلوک فعلی blockN باشد، اعتبارسنجی‌هایی که شاخص‌های زیر را دارند، حقوق اولویت تولید بلوک را به دست می‌آورند.
buddh0 این گفتگو را به عنوان حل شده علامت گذاری کرد.
< div align = " center " >
<img src=./assets/bep-341/4.2.1.png عرض=36% />
</ div >

4.2.2 سوئیچ مجموعه اعتبار سنجی

هر دوره یک مجموعه اعتبار سنجی جدید را انتخاب می کند، با این فرض که یک دوره حاوی اسلات های epochSlots است. سوئیچ تنظیم اعتبار سنج فقط زمانی رخ می دهد که ارتفاع بلوک به Bswitch برسد تا از جعل بلوک دوره ای جلوگیری شود. محاسبه Bswitch به شرح زیر است:
< div align = " center " >
<img src=./assets/bep-341/4.2.2.png عرض=56% />
</ div >

4.2.3 اجتناب از بلوک

برای جلوگیری از کنترل کمتر از 1/2 گره ها بر کل شبکه، تولیدکنندگان بلوک باید کمتر از n بلوک را در بلوک های تاریخی قبلی ((validatorN/2+1) * n-1) تولید کنند.

4.2.4 تعداد بلوک های متوالی قابل اداره

وقتی n=1، معادل غیرفعال کردن ویژگی تولید بلوک های متوالی است، در حالی که بهینه سازی قابل توجهی مشاهده می شود که n به محدوده [ 3،5 ] تعلق دارد . در حال حاضر، محدوده برای مقدار n بر روی [ 1،9 ] تنظیم شده است اما به جز 2.

مقدار اولیه n 1 است و تغییر مقدار آن نیازمند فرآیند حاکمیت BSC است.

4.2.5 مبارزه با MEV

NathanBSC این گفتگو را به عنوان حل شده علامت گذاری کرد.
از آنجایی که دوره متوالی که در آن یک اعتبارسنجی منفرد در تولید بلوک اولویت پیدا می‌کند، ممکن است استخراج MEV را تسهیل کند، و به طور بالقوه اعتبارسنجی‌ها را به گنجاندن تراکنش‌های بیشتری در بلوک‌های بعدی که متوالی تولید می‌کنند، سوق می‌دهد. برای محدود کردن اعتبارسنجی‌ها به بسته‌بندی سریع تراکنش‌ها، در اولویت‌های متوالی اعتبارسنجی نسبت به n بلوک، تقسیم کارمزد تراکنش به SystemRewardContract به صورت خطی با شماره بلوک افزایش می‌یابد که با مقدار نشان داده شده به عنوان systemRewardAntiMEVRatio محدود می‌شود.
به ترتیب، نسبت تقسیم در systemRewardBaseRatio باقی می‌ماند که تولید بلوک پیوسته غیرفعال باشد. هنگامی که تولید بلوک پیوسته فعال می شود (یعنی زمانی که n> 1 باشد)، نسبت systemReward به صورت زیر محاسبه می شود:
< div align = " center " >
<img src=./assets/bep-341/4.2.5-1.png عرض=150% />
</ div >
همانطور که در تصویر زیر نشان داده شده است:
< div align = " center " >
<img src=./assets/bep-341/4.2.5-2.png عرض=75% />
</ div >

مقدار اولیه systemRewardAntiMEVRatio 0 است و تغییر مقدار آن به فرآیند حاکمیت BSC نیز نیاز دارد.

5. تجزیه و تحلیل انصاف انگیزه

در یک دوره واحد، اعتبارسنجی‌های دم فرصت‌های تولید بلوک کمتری دارند، اما تخصیص حقوق اولویت بی‌طرفانه است و نمی‌توان آن را دستکاری کرد. بنابراین از منظر آماری منصفانه است.

اگر یک اعتبارسنجی سعی کند MEV بیشتری را با قرار دادن تراکنش های بیشتر در بلوک های بعدی که تولید می کند استخراج کند، زمان تأیید تراکنش کاربر را نیز افزایش می دهد. برای مهار این امر، SystemRewardAntiMEVRatio را می توان از طریق فرآیند حاکمیت افزایش داد، که باعث افزایش نسبت کارمزد تراکنش تخصیص یافته به SystemRewardContract می شود. این پاداش‌ها به‌عنوان جوایز رای‌گیری Fast Finality بین اعتبارسنجی‌کنندگان توزیع می‌شود و مزایای کلی آن‌ها بدون تغییر باقی می‌ماند. با این حال، در طول ترافیک بالا و عقب ماندگی تراکنش ها، اعتبار سنجی های با عملکرد بالا معمولا تراکنش های بیشتری را انجام می دهند. این تغییرات مزیت درآمدی داشتن عملکرد بالا را کاهش خواهد داد.

6. تجزیه و تحلیل امنیتی

این BEP بر ویژگی Fast Finality BSC متکی است. اگر Fast Finality ناموفق باشد، ممکن است منجر به مشکلات زیر شود:
1 . گره ها عمداً بلوک های استخراج شده را پنهان می کنند و به طور بالقوه منجر به سازماندهی مجدد کوتاه مدت طولانی تر می شوند.
2 . احتمال نهایی شدن تراکنش ها افزایش می یابد و نیاز به انتظار برای 2/3 * validatorN * n+ بلوک است.

120 تغییر: 120 اضافه و 0 حذف120
BEPs/BEP-341.md
Copied!
شماره خط فایل اصلی شماره خط تفاوت تغییر خط تفاوت
@@ -0،0 +1120 @@
< پیش >
BEP: 341
عنوان: اعتبار سنجی ها می توانند بلوک های متوالی تولید کنند
وضعیت: پیش نویس
نوع: استاندارد
ایجاد: 27/09/2023
بحث‌ها (اختیاری): https://forum.bnbchain.org/t/bep-idea-validators-can-produce-consecutive-blocks/2052
</ pre >

BEP-341: اعتبار سنجی ها می توانند بلوک های متوالی تولید کنند

[ BEP-341: اعتبار سنجی ها می توانند بلوک های متوالی تولید کنند ] ( #bep-341-validators-can-produce-consecutive-blocks )
[ 1. خلاصه ] ( Add BEP1&2 proposals #1-خلاصه )
[ 2. چکیده ] ( Edit index on BEP2 #2-چکیده )
[ 3. انگیزه ] ( BEP3: Add HTLC #3-انگیزه )
[ 4. مشخصات ] ( BEP4: 256-bit Tokens #4-مشخصات )
- [ 4.1 اصل مقیاس‌بندی ] ( Whitelist Script for BEP12 #41-scaling-principle )
- [ 4.2 Implementation Specification ] ( Register TrustToken Source #42-implementation-specification )
- [ 4.2.1 تخصیص اولویت ] ( Trust wallet #421-priority-allocation )
- [ 4.2.2 سوئیچ تنظیم اعتبار ] ( Trust wallet #422-validator-set-switch )
- [ 4.2.3 Block Avoidance ] ( Trust wallet #423-block-avoidance )
- [ 4.2.4 تعداد بلوک های متوالی قابل اداره ] ( Bttc #424-governable-number-of-consecutive-blocks )
- [ 4.2.5 Combatting MEV ] ( BEP-425: Hint based Parallel Transaction Execution #425-combatting-mev )
[ 5. تحلیل انصاف انگیزشی ] ( BEP-5: Token Resources [IMPROVEMENT] #5-انگیزه-انصاف-تحلیل )
[ 6. تجزیه و تحلیل امنیتی ] ( BEP-6: Add delist proposal #6-security-analysis )
[ 7. تجزیه و تحلیل Liveness ] ( BEP 7: Bring Non-fungible Tokens(NFTs) to Binance Chain and expand the use cases. #7-liveness-analysis )
[ 8. مجوز ] ( Fix BEP2 markdown style. #8-مجوز )

1. خلاصه

هر دوره در BSC از چندین اسلات تشکیل شده است و دسته ای از اعتبار سنجی ها به نوبت به ترتیب از پیش تعریف شده برای به دست آوردن حقوق اولویت تولید بلوک برای هر شکاف به کار می روند. این BEP تنظیمی را برای تخصیص حقوق تولید بلوک اولویتی پیشنهاد می کند: هر اعتبارسنجی حقوق تولید بلوک اولویت را برای تعداد از پیش تعیین شده اسلات های متوالی در هر دور دریافت می کند.

2. چکیده

BEP-341 یک روش تخصیص جدید برای حقوق تولید بلوک اولویتی را توصیف می کند، که از نظر منطقی مختصر است و ظرفیت پردازش تراکنش سیستم را به طور قابل توجهی افزایش می دهد، در حالی که متعامد به تکنیک های بهینه سازی پردازش تراکنش در داخل بلوک ها باقی می ماند.

3. انگیزه

اکوسیستم BSC فعال و پیوسته در حال تکامل است و به بهبود مستمر ظرفیت پردازش تراکنش سیستم نیاز دارد.

4. مشخصات

4.1 اصل مقیاس بندی

در حال حاضر، هر اعتبارسنجی حق تولید بلوک اولویت را برای یک شکاف به دست می‌آورد و سپس با فاصله بلوک ثابت t می‌چرخد. حد پردازش تراکنش t/2 برای اعتبارسنجی تراکنش های بلوک قبلی و t/2 برای پردازش تراکنش ها در بلوک جدید است.
< div align = " center " >
<img src=./assets/bep-341/4.1-1.png عرض=60% />
</ div >
با فرض اینکه تعداد تراکنش های قابل پردازش T باشد، میانگین TPS به صورت زیر محاسبه می شود:
< div align = " center " >
<img src=./assets/bep-341/4.1-2.png عرض=18% />
</ div >
پس از اجرای این BEP، هر اعتبارسنجی می‌تواند حقوق تولید بلوک اولویت را برای یک دنباله پیوسته از n اسلات در یک دور بدست آورد. اولین بلوکی که آنها پردازش می کنند هنوز t/2 را برای اعتبارسنجی تراکنش های بلوک قبلی و t/2 را برای پردازش تراکنش ها در بلوک جدید اختصاص می دهد. با این حال، بلوک‌های بعدی می‌توانند فرآیند اعتبارسنجی تراکنش را نادیده بگیرند و روی پردازش تراکنش‌ها در بلوک جدید تمرکز کنند. توصیه می‌شود که زمان پردازش آخرین بلوک در دور فعلی فقط نیمی از زمان مورد نیاز برای پردازش تراکنش‌ها در بلوک جدید باشد. این به جلوگیری از موقعیتی کمک می کند که اولین بلوک پردازش شده توسط اعتبارسنجی بعدی نزدیک به یک بلوک خالی باشد.
< div align = " center " >
<img src=./assets/bep-341/4.1-3.png عرض=60% />
</ div >
TPS پس از تولید بلوک پیوسته به شرح زیر است:
< div align = " center " >
<img src=./assets/bep-341/4.1-4.png عرض=50% />
</ div >
بنابراین، نرخ بهبود TPS:
< div align = " center " >
<img src=./assets/bep-341/4.1-5.png عرض=40% />
</ div >
رابطه بین تعداد بلوک های پیوسته تولید شده و بهبود TPS وجود دارد
< div align = " center " >
<img src=./assets/bep-341/4.1-6.png عرض=60% />
</ div >
همانطور که در نمودار نشان داده شده است، واضح است که تولید بلاک پیوسته نمی تواند TPS را دو برابر کند. وقتی n<3 فایده ای ندارد، و افزایش n بیش از 5 به طور متناسبی مزایا را افزایش نمی دهد. بنابراین، مقداری در محدوده [ 3، 5 ] برای n مناسب است. زمانی که n=4، r=50%.

4.2 مشخصات پیاده سازی

4.2.1 تخصیص اولویت

هر دوره مجموعه‌ای از اعتبار‌دهنده‌ها را از پیش تعریف می‌کند، با مجموع اعتبار‌دهنده‌های validatorN، و هر اعتبارسنجی درون مجموعه دارای یک شاخص منحصربه‌فرد در محدوده [ 0، validatorN) است. اگر ارتفاع بلوک فعلی blockN باشد، اعتبارسنجی‌هایی که شاخص‌های زیر را دارند، حقوق اولویت تولید بلوک را به دست می‌آورند.
buddh0 این گفتگو را به عنوان حل شده علامت گذاری کرد.
< div align = " center " >
<img src=./assets/bep-341/4.2.1.png عرض=36% />
</ div >

4.2.2 سوئیچ مجموعه اعتبار سنجی

هر دوره یک مجموعه اعتبار سنجی جدید را انتخاب می کند، با این فرض که یک دوره حاوی اسلات های epochSlots است. سوئیچ تنظیم اعتبار سنج فقط زمانی رخ می دهد که ارتفاع بلوک به Bswitch برسد تا از جعل بلوک دوره ای جلوگیری شود. محاسبه Bswitch به شرح زیر است:
< div align = " center " >
<img src=./assets/bep-341/4.2.2.png عرض=56% />
</ div >

4.2.3 اجتناب از بلوک

برای جلوگیری از کنترل کمتر از 1/2 گره ها بر کل شبکه، تولیدکنندگان بلوک باید کمتر از n بلوک را در بلوک های تاریخی قبلی ((validatorN/2+1) * n-1) تولید کنند.

4.2.4 تعداد بلوک های متوالی قابل اداره

وقتی n=1، معادل غیرفعال کردن ویژگی تولید بلوک های متوالی است، در حالی که بهینه سازی قابل توجهی مشاهده می شود که n به محدوده [ 3،5 ] تعلق دارد . در حال حاضر، محدوده برای مقدار n بر روی [ 1،9 ] تنظیم شده است اما به جز 2.

مقدار اولیه n 1 است و تغییر مقدار آن نیازمند فرآیند حاکمیت BSC است.

4.2.5 مبارزه با MEV

NathanBSC این گفتگو را به عنوان حل شده علامت گذاری کرد.
از آنجایی که دوره متوالی که در آن یک اعتبارسنجی منفرد در تولید بلوک اولویت پیدا می‌کند، ممکن است استخراج MEV را تسهیل کند، و به طور بالقوه اعتبارسنجی‌ها را به گنجاندن تراکنش‌های بیشتری در بلوک‌های بعدی که متوالی تولید می‌کنند، سوق می‌دهد. برای محدود کردن اعتبارسنجی‌ها به بسته‌بندی سریع تراکنش‌ها، در اولویت‌های متوالی اعتبارسنجی نسبت به n بلوک، تقسیم کارمزد تراکنش به SystemRewardContract به صورت خطی با شماره بلوک افزایش می‌یابد که با مقدار نشان داده شده به عنوان systemRewardAntiMEVRatio محدود می‌شود.
به ترتیب، نسبت تقسیم در systemRewardBaseRatio باقی می‌ماند که تولید بلوک پیوسته غیرفعال باشد. هنگامی که تولید بلوک پیوسته فعال می شود (یعنی زمانی که n> 1 باشد)، نسبت systemReward به صورت زیر محاسبه می شود:
< div align = " center " >
<img src=./assets/bep-341/4.2.5-1.png عرض=150% />
</ div >
همانطور که در تصویر زیر نشان داده شده است:
< div align = " center " >
<img src=./assets/bep-341/4.2.5-2.png عرض=75% />
</ div >

مقدار اولیه systemRewardAntiMEVRatio 0 است و تغییر مقدار آن به فرآیند حاکمیت BSC نیز نیاز دارد.

5. تجزیه و تحلیل انصاف انگیزه

در یک دوره واحد، اعتبارسنجی‌های دم فرصت‌های تولید بلوک کمتری دارند، اما تخصیص حقوق اولویت بی‌طرفانه است و نمی‌توان آن را دستکاری کرد. بنابراین از منظر آماری منصفانه است.

اگر یک اعتبارسنجی سعی کند MEV بیشتری را با قرار دادن تراکنش های بیشتر در بلوک های بعدی که تولید می کند استخراج کند، زمان تأیید تراکنش کاربر را نیز افزایش می دهد. برای مهار این امر، SystemRewardAntiMEVRatio را می توان از طریق فرآیند حاکمیت افزایش داد، که باعث افزایش نسبت کارمزد تراکنش تخصیص یافته به SystemRewardContract می شود. این پاداش‌ها به‌عنوان جوایز رای‌گیری Fast Finality بین اعتبارسنجی‌کنندگان توزیع می‌شود و مزایای کلی آن‌ها بدون تغییر باقی می‌ماند. با این حال، در طول ترافیک بالا و عقب ماندگی تراکنش ها، اعتبار سنجی های با عملکرد بالا معمولا تراکنش های بیشتری را انجام می دهند. این تغییرات مزیت درآمدی داشتن عملکرد بالا را کاهش خواهد داد.

6. تجزیه و تحلیل امنیتی

این BEP بر ویژگی Fast Finality BSC متکی است. اگر Fast Finality ناموفق باشد، ممکن است منجر به مشکلات زیر شود:
1 . گره ها عمداً بلوک های استخراج شده را پنهان می کنند و به طور بالقوه منجر به سازماندهی مجدد کوتاه مدت طولانی تر می شوند.
2 . احتمال نهایی شدن تراکنش ها افزایش می یابد و نیاز به انتظار برای 2/3 * validatorN * n+ بلوک است.

7. تجزیه و تحلیل Liveness

زنده بودن زنجیره بدون تغییر باقی می ماند، به این معنی که باید اطمینان حاصل شود که حداقل اعتبار سنجی (validatorN/2+1) فعال هستند. اثبات به شرح زیر است:

اگر اعتبار سنجی (validatorN/2+1) فعال باشد و هیچ کدام مجاز به تولید بلوک در یک لحظه خاص نباشد، هر اعتبارسنجی باید حداقل n بلوک در بلوک های گذشته ((validatorN/2+1) * n-1) تولید کرده باشد. . بنابراین، در مجموع، حداقل (validatorN/2+1) * n بلوک باید تولید شده باشد که غیرممکن است. بنابراین، در هر لحظه، حداقل یکی از اعتبار سنجی (validatorN/2+1) باید اجازه تولید بلوک را داشته باشد.

8. مجوز

محتوا تحت مجوز [ CC0 ] ( https://creativecommons.org/publicdomain/zero/1.0/ ) است .
فایل باینری اضافه شدBIN +40.4 کیلوبایت
BEPs/assets/bep-341/4.1-1.png
در حال بارگذاری
فایل باینری اضافه شدBIN + 12.4 کیلوبایت
BEPs/assets/bep-341/4.1-2.png
در حال بارگذاری
فایل باینری اضافه شدBIN +41.6 کیلوبایت
BEPs/assets/bep-341/4.1-3.png
در حال بارگذاری
فایل باینری اضافه شدBIN +31.8 کیلوبایت
BEPs/assets/bep-341/4.1-4.png
در حال بارگذاری
فایل باینری اضافه شدBIN + 25.8 کیلوبایت

NathanBSC force-pushed the bep-234-validators-can-produce-consecutive-blocks branch from 84ddb82 to 1b36e3f Compare January 12, 2024 13:55

NathanBSC changed the title ~~BEP-301: Validators can produce consecutive blocks~~ BEP-341: Validators can produce consecutive blocks Jan 12, 2024

Bbjj88h approved these changes Feb 17, 2024

View reviewed changes

Fdutoit96 approved these changes Feb 17, 2024

View reviewed changes

yoshidan mentioned this pull request Mar 4, 2024

Check validator rotation and difficulty datachainlab/parlia-elc#45

Closed

NathanBSC force-pushed the bep-234-validators-can-produce-consecutive-blocks branch 3 times, most recently from d94ca83 to d2994d5 Compare April 23, 2024 11:57

buddh0 assigned will-2012 and unassigned will-2012 Apr 26, 2024

NathanBSC force-pushed the bep-234-validators-can-produce-consecutive-blocks branch from 9ba10b6 to f4537f1 Compare April 29, 2024 04:23

Bbjj88h approved these changes Apr 30, 2024

View reviewed changes

NathanBSC force-pushed the bep-234-validators-can-produce-consecutive-blocks branch from 1320f5b to ce0b5be Compare May 10, 2024 03:04

NathanBSC mentioned this pull request May 20, 2024

BEP-341: Validators can produce consecutive blocks bnb-chain/bsc#2482

Merged

NathanBSC force-pushed the bep-234-validators-can-produce-consecutive-blocks branch from 4341461 to 494d4f4 Compare May 29, 2024 02:52

buddh0 force-pushed the bep-234-validators-can-produce-consecutive-blocks branch from 494d4f4 to f0939e1 Compare June 4, 2024 10:48

MatusKysel reviewed Jun 5, 2024

View reviewed changes

BEPs/BEP-341.md Show resolved Hide resolved

MatusKysel reviewed Jun 5, 2024

View reviewed changes

BEPs/BEP-341.md Outdated Show resolved Hide resolved

emailtovamos reviewed Jun 5, 2024

View reviewed changes

BEPs/BEP-341.md Show resolved Hide resolved

NathanBSC force-pushed the bep-234-validators-can-produce-consecutive-blocks branch from d7cf196 to 6cd2582 Compare June 11, 2024 01:58

NathanBSC force-pushed the bep-234-validators-can-produce-consecutive-blocks branch from 616c347 to 9f2cdd7 Compare June 12, 2024 09:04

huihzhao approved these changes Jun 12, 2024

View reviewed changes

bnb-chain deleted a comment from NathanBSC Jul 8, 2024

NathanBSC added 2 commits July 25, 2024 18:26

BEP-341: Validators can produce consecutive blocks

58a3056

BEP-341: combatting MEV

445b803

NathanBSC added 10 commits July 25, 2024 18:26

BEP-341: keep distributing FinalityReward at Epoch Block

9847f02

BEP-341: make minRatio and maxRatio governable

5580a8f

BEP-341: add liveness analysis

9145dad

delete 4.2.2-2.png

3be13e6

update Combatting MEV

7210171

rename vars about combatting MEV

8626f57

add \ before *

b07573c

remove the space before

d9ebabc

change the length of block history to check

818205f

add detail impact on users and validators by Combatting MEV

0857967

NathanBSC force-pushed the bep-234-validators-can-produce-consecutive-blocks branch from 9f2cdd7 to 0857967 Compare July 25, 2024 10:27

zzzckck approved these changes Jul 29, 2024

View reviewed changes

zzzckck merged commit 048b73b into bnb-chain:master Jul 29, 2024

yutianwu mentioned this pull request Jul 29, 2024

feat: implement the Bohr upgrade of BSC bnb-chain/reth#86

Merged

Aces42020 approved these changes Sep 20, 2024

View reviewed changes

galaio pushed a commit to galaio/BEPs that referenced this pull request Nov 1, 2024

BEP-341: Validators can produce consecutive blocks (bnb-chain#341)

12e9a7c

Mofidzol reviewed Jan 19, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

BEP-341: Validators can produce consecutive blocks #341

BEP-341: Validators can produce consecutive blocks #341

NathanBSC commented Jan 12, 2024 •

edited

Loading

Magkoohp commented Jan 13, 2024

huihzhao commented Jun 12, 2024

buddh0 commented Jun 12, 2024 •

edited

Loading

thy-r commented Jun 19, 2024

huihzhao commented Jun 19, 2024

NathanBSC commented Jul 25, 2024 •

edited

Loading

Mofidzol left a comment

BEP-341: Validators can produce consecutive blocks #341

BEP-341: Validators can produce consecutive blocks #341

Conversation

NathanBSC commented Jan 12, 2024 • edited Loading

BEP-341: Validators can produce consecutive blocks

1. Summary

2. Abstract

3. Motivation

4. Specification

4.1 Scaling Principle

4.2 Implementation Specification

4.2.1 Priority Allocation

4.2.2 Validator Set Switch

4.2.3 Block Avoidance

4.2.4 Governable Number of Consecutive Blocks

4.2.5 Combatting MEV

5. Incentive Fairness Analysis

6. Security Analysis

7. Liveness Analysis

8. License

Magkoohp commented Jan 13, 2024

huihzhao commented Jun 12, 2024

buddh0 commented Jun 12, 2024 • edited Loading

thy-r commented Jun 19, 2024

huihzhao commented Jun 19, 2024

NathanBSC commented Jul 25, 2024 • edited Loading

Mofidzol left a comment

Choose a reason for hiding this comment

BEP-341: اعتبار سنجی ها می توانند بلوک های متوالی تولید کنند

1. خلاصه

2. چکیده

3. انگیزه

4. مشخصات

4.1 اصل مقیاس بندی

4.2 مشخصات پیاده سازی

4.2.1 تخصیص اولویت

4.2.2 سوئیچ مجموعه اعتبار سنجی

4.2.3 اجتناب از بلوک

4.2.4 تعداد بلوک های متوالی قابل اداره

4.2.5 مبارزه با MEV

5. تجزیه و تحلیل انصاف انگیزه

6. تجزیه و تحلیل امنیتی

7. تجزیه و تحلیل Liveness

8. مجوز

BEP-341: اعتبار سنجی ها می توانند بلوک های متوالی تولید کنند

1. خلاصه

2. چکیده

3. انگیزه

4. مشخصات

4.1 اصل مقیاس بندی

4.2 مشخصات پیاده سازی

4.2.1 تخصیص اولویت

4.2.2 سوئیچ مجموعه اعتبار سنجی

4.2.3 اجتناب از بلوک

4.2.4 تعداد بلوک های متوالی قابل اداره

4.2.5 مبارزه با MEV

5. تجزیه و تحلیل انصاف انگیزه

6. تجزیه و تحلیل امنیتی

BEP-341: اعتبار سنجی ها می توانند بلوک های متوالی تولید کنند

1. خلاصه

2. چکیده

3. انگیزه

4. مشخصات

4.1 اصل مقیاس بندی

4.2 مشخصات پیاده سازی

4.2.1 تخصیص اولویت

4.2.2 سوئیچ مجموعه اعتبار سنجی

4.2.3 اجتناب از بلوک

4.2.4 تعداد بلوک های متوالی قابل اداره

4.2.5 مبارزه با MEV

5. تجزیه و تحلیل انصاف انگیزه

6. تجزیه و تحلیل امنیتی

7. تجزیه و تحلیل Liveness

8. مجوز

NathanBSC commented Jan 12, 2024 •

edited

Loading

buddh0 commented Jun 12, 2024 •

edited

Loading

NathanBSC commented Jul 25, 2024 •

edited

Loading