Bahamut Execution and Consensus

Files: - `beacon-chain/core/helpers/validators.go` - `beacon-chain/core/altair/sync_committee.go` Commit: - [`33b75d4e162179d360e60ac88bb4289293b530a6`](https://github.com/fastexlabs/bahamut-consensus/tree/33b75d4e162179d360e60ac88bb4289293b530a6) According to the current codebase, the block producer and sync committee member selection inherits the algorithm from the RANDAO randomness generation in the Ethereum Proof of Stake. Before the version `FastexPhase1`, the implementation contains some modifications that use the sigmoid function and validator's power defined by the validator's activity score. In Ethereum Proof of Stake, the selection is performed through a shuffle to make the list of active validators randomly, then for each validator, a random number `rand` is generated between 0 and `MaxRand` to check if the inequality $$\frac{s_i}{s} \geq \frac{rand}{MaxRand}$$ holds, where $s_i$ is the effective balance of the validator $i$ and $s$ is the max effective balance. In the Fasttoken, the same approach is adopted with the following changes in the inequality $$(2\cdot \frac{1}{1+e^{-1.5 \cdot \frac{P_i}{P}}} - 1) \cdot \frac{s_i}{s} \geq \frac{rand}{MaxRand} \cdot 0.62$$ The sigmoid function on the left is used to adjust the effective balance of the validator, where the $P_i$ is the power of the validator $i$ and $P$ is the max power of all the validators.

Files: - `beacon-chain/core/helpers/beacon_committee.go` - `beacon-chain/core/helpers/validators.go` - `beacon-chain/core/altair/sync_committee.go` Commit: - [`33b75d4e162179d360e60ac88bb4289293b530a6`](https://github.com/fastexlabs/bahamut-consensus/tree/33b75d4e162179d360e60ac88bb4289293b530a6) In both functions `BeaconProposerIndex()` and `precomputeProposerIndices()`, an `if-else` logic is coded to select the function for computing the index of the proposer based on the `Version`. The function `BeaconProposerIndex()` in **beacon-chain/core/helpers/validators.go**: ```go=301 if state.Version() < version.FastexPhase1 { return ComputeProposerIndex(state, indices, seedWithSlotHash) } return ComputeProposerIndexFastexPhase1(state, indices, seedWithSlotHash) ``` The function `precomputeProposerIndices()` in **beacon-chain/core/helpers/beacon_committee.go**: ```go=453 if state.Version() < version.FastexPhase1 { index, err = ComputeProposerIndex(state, activeIndices, seedWithSlotHash) if err != nil { return nil, err } } else { index, err = ComputeProposerIndexFastexPhase1(state, activeIndices, seedWithSlotHash) if err != nil { return nil, err } } proposerIndices[i] = index ``` Based on our understanding, when the version is before the `FastexPhase1`, the consensus client should still be in `PoS` mode, and the logic for calculating the index of the proposer should be the same as in Ethereum. However, in the implementation, the `ComputeProposerIndex()` function takes not only the **effective balance** of the validator but also the **effective activity**, which should be calculated in the `PoSA` mode. The function `ComputeProposerIndex()` in **beacon-chain/core/helpers/validators.go**: ```go=384 // ComputeProposerIndex returns the index sampled by effective balance, which is used to calculate the proposer. func ComputeProposerIndex(bState state.ReadOnlyBeaconState, activeIndices []primitives.ValidatorIndex, seed [32]byte) (primitives.ValidatorIndex, error) { length := uint64(len(activeIndices)) if length == 0 { return 0, errors.New("empty active indices list") } maxRandomByte := new(big.Float).SetUint64(1<<16 - 1) hashFunc := hash.CustomSHA256Hasher() txGasPerPeriod := bState.TransactionsGasPerPeriod() var nonStakersGasPerPeriod uint64 // Ignore nonStakersGasPerPeriod in post-FastexPhase1 fork. if bState.Version() < version.FastexPhase1 { nonStakersGasPerPeriod = bState.NonStakersGasPerPeriod() } ... ``` In addition, a similar scenario occurs in the sync committee members selection: **beacon-chain/core/altair/sync_committee.go** ```go=61 func NextSyncCommittee(ctx context.Context, s state.BeaconState) (*ethpb.SyncCommittee, error) { var indices []primitives.ValidatorIndex var err error if s.Version() < version.FastexPhase1 { indices, err = NextSyncCommitteeIndices(ctx, s) } else { indices, err = NextSyncCommitteeIndicesFastexPhase1(ctx, s) } ``` Before the `FastexPhase1`, the `NextSyncCommittee()` calls the `NextSyncCommitteeIndices()` that needs the activity score to compute the validator power: **beacon-chain/core/altair/sync_committee.go** ```go=88 func NextSyncCommitteeIndices(ctx context.Context, s state.BeaconState) ([]primitives.ValidatorIndex, error) { epoch := coreTime.NextEpoch(s) indices, err := helpers.ActiveValidatorIndices(ctx, s, epoch) if err != nil { return nil, err } seed, err := helpers.Seed(s, epoch, params.BeaconConfig().DomainSyncCommittee) if err != nil { return nil, err } count := uint64(len(indices)) cfg := params.BeaconConfig() syncCommitteeSize := cfg.SyncCommitteeSize cIndices := make([]primitives.ValidatorIndex, 0, syncCommitteeSize) hashFunc := hash.CustomSHA256Hasher() txGasPerPeriod := s.TransactionsGasPerPeriod() var nonStakersGasPerPeriod uint64 // Ignore nonStakersGasPerPeriod in post-FastexPhase1 forks. if s.Version() < version.FastexPhase1 { nonStakersGasPerPeriod = s.NonStakersGasPerPeriod() } ... ``` In the post `FastexPhase1`, it invokes the `NextSyncCommitteeIndicesFastexPhase1()` that only utilizes the **effective balance**: ```go=174 func NextSyncCommitteeIndicesFastexPhase1(ctx context.Context, s state.BeaconState) ([]primitives.ValidatorIndex, error) { epoch := coreTime.NextEpoch(s) indices, err := helpers.ActiveValidatorIndices(ctx, s, epoch) if err != nil { return nil, err } seed, err := helpers.Seed(s, epoch, params.BeaconConfig().DomainSyncCommittee) if err != nil { return nil, err } count := uint64(len(indices)) cfg := params.BeaconConfig() syncCommitteeSize := cfg.SyncCommitteeSize cIndices := make([]primitives.ValidatorIndex, 0, syncCommitteeSize) hashFunc := hash.CustomSHA256Hasher() for i := primitives.ValidatorIndex(0); uint64(len(cIndices)) < params.BeaconConfig().SyncCommitteeSize; i++ { if ctx.Err() != nil { return nil, ctx.Err() } ... ```

Files: - `beacon-chain/core/altair/sync_committee.go` - `beacon-chain/core/helpers/validators.go` - `config/params/testnet_fastex_chain_config.go` Commit: - [`33b75d4e162179d360e60ac88bb4289293b530a6`](https://github.com/fastexlabs/bahamut-consensus/tree/33b75d4e162179d360e60ac88bb4289293b530a6) The block producer and sync committee member selection inherits the algorithm from the RANDAO randomness generation in the Ethereum Proof of Stake. In Ethereum Proof of Stake, the selection is performed through a shuffle to make the list of active validators randomly, then for each validator, a random number `rand` is generated between 0 and `MaxRand` to check if the inequality $$\frac{s_i}{s} \geq \frac{rand}{MaxRand}$$ holds, where $s_i$ is the effective balance of the validator $i$ and $s$ is the max effective balance. In the Fasttoken, the same approach is adopted with the following modification in the inequality $$(2\cdot \frac{1}{1+e^{-1.5 \cdot \frac{P_i}{P}}} - 1) \cdot \frac{s_i}{s} \geq \frac{rand}{MaxRand} \cdot 0.62$$ The sigmoid function on the left is used to adjust the effective balance of the validator, where the $P_i$ is the voting power of the validator $i$ and $P$ is the max voting power of all the validators. The current value of `SigmoidLimit` is **0.62** on the right, but the maximum value of the sigmoid function $2\cdot \frac{1}{1+e^{-1.5 \cdot \frac{P_i}{P}}} - 1$ is around **0.635** when the $P_i$ equals to $P$. In this case, if the voting power of validator $i$, $P_i = P * 97\%$, then the value of the sigmoid is **0.62**. That means a validator only needs $97\%$ (not $100\%$) of the maximum voting power $P$ to obtain the same formula as the Ethereum Proof of Stake.

Files: - `beacon-chain/core/altair/sync_committee.go` - `beacon-chain/core/helpers/validators.go` Commit: - [`33b75d4e162179d360e60ac88bb4289293b530a6`](https://github.com/fastexlabs/bahamut-consensus/tree/33b75d4e162179d360e60ac88bb4289293b530a6) According to the Fasttoken consensus whitepaper, the voting power of validator $i$ is defined as: $$ P^e_i = T_e \cdot \frac{s_i}{S} + A^e_{V_i},$$ where $T_e$ is the sum of all transaction constant gas usage components, that is, $T_e = 21000 ∗ N$ where N is the number of all transactions which have been executed during the epoch $e$. However, in line 389 of the implementation: **beacon-chain/core/helpers/validators.go**, **beacon-chain/core/altair/sync_committee.go** ```go=343 func ComputeProposerIndex(bState state.ReadOnlyBeaconState, activeIndices []primitives.ValidatorIndex, seed [32]byte) (primitives.ValidatorIndex, error) { length := uint64(len(activeIndices)) if length == 0 { return 0, errors.New("empty active indices list") } maxRandomByte := new(big.Float).SetUint64(1<<16 - 1) hashFunc := hash.CustomSHA256Hasher() txGasPerPeriod := bState.TransactionsGasPerPeriod() var nonStakersGasPerPeriod uint64 // Ignore nonStakersGasPerPeriod in post-FastexPhase1 fork. if bState.Version() < version.FastexPhase1 { nonStakersGasPerPeriod = bState.NonStakersGasPerPeriod() } totalBalance := TotalBalance(bState, activeIndices) maxPower, err := MaxPower(bState, activeIndices, totalBalance, txGasPerPeriod, nonStakersGasPerPeriod) maxPowerFloat := new(big.Float).SetInt(maxPower) if err != nil { return 0, err } for i := uint64(0); ; i++ { candidateIndex, err := ComputeShuffledIndex(primitives.ValidatorIndex(i%length), length, seed, true /* shuffle */) if err != nil { return 0, err } candidateIndex = activeIndices[candidateIndex] if uint64(candidateIndex) >= uint64(bState.NumValidators()) { return 0, errors.New("active index out of range") } b := append(seed[:], bytesutil.Bytes8(i/16)...) hash := hashFunc(b) bytes2 := append([]byte{}, hash[i%16], hash[16+i%16]) randomBytes := new(big.Float).SetUint64(uint64(bytesutil.FromBytes2(bytes2))) v, err := bState.ValidatorAtIndexReadOnly(candidateIndex) if err != nil { return 0, err } totalBalanceBig := new(big.Int).SetUint64(totalBalance / params.BeaconConfig().EffectiveBalanceIncrement) effectiveBalanceBig := new(big.Int).SetUint64(v.EffectiveBalance() / params.BeaconConfig().EffectiveBalanceIncrement) effectiveActivityBig := new(big.Int).SetUint64(v.EffectiveActivity()) txGasBig := new(big.Int).SetUint64(txGasPerPeriod) nonStakersGasBig := new(big.Int).SetUint64(nonStakersGasPerPeriod) var power *big.Int power = new(big.Int).Add(txGasBig, nonStakersGasBig) power = new(big.Int).Mul(power, effectiveBalanceBig) power = new(big.Int).Div(power, totalBalanceBig) power = new(big.Int).Add(power, effectiveActivityBig) ... ``` $$T_e = T + B$$, where $T$ is the aggregation of the constant gas usage argument equal to 21000, and $B$ is the gas usage of smart contracts not associated with any validator, both of which are calculated in the sliding window of 1575 epochs, not in each epoch. The $B$ part, `nonStakersGasBig` is zero only in the post-FastexPhase1 fork (shown in lines 354-356), which matches the formula in the whitepaper.

Files: - `config/params/mainnet_config.go` - `config/params/minimal_config.go` Commit: - [`3b8da2895d7067405b54c0829eee7e044a0f978e`](https://github.com/fastexlabs/bahamut-consensus/tree/3b8da2895d7067405b54c0829eee7e044a0f978e) The parameters `MaxEffectiveBalance` and `EjectionBalance` were properly set in the configuration file `testnet_fastex_chain_config.go`. However, they were not updated in the configuration file `mannet_config.go` to accommodate the new features and functionality. A misconfiguration could cause errors or bugs that could negatively impact the functionality of the project. ```go=92 MaxEffectiveBalance: 32 * 1e9, EjectionBalance: 16 * 1e9, ``` In addition, the below parameters in the configuration file `minimal_config.go` are not properly set. ```go=20 MinGenesisTime: 1606824000, // Dec 1, 2020, 12pm UTC. ``` ```go=25 minimalConfig.MinDepositAmount = 1e9 minimalConfig.MaxEffectiveBalance = 32e9 minimalConfig.EjectionBalance = 16e9 minimalConfig.EffectiveBalanceIncrement = 1e9 ```

Files: - `beacon-chain/core/fastex-phase1/attestation.go` Commit: - [`33b75d4e162179d360e60ac88bb4289293b530a6`](https://github.com/fastexlabs/bahamut-consensus/tree/33b75d4e162179d360e60ac88bb4289293b530a6) The function `RewardProposer()` is intended to calculate the reward for the block proposer, which accepts the parameters, `proposerRewardNumerator` and `proposerRewardDenominator` from the return values of function `EpochParticipation()`. If the passed `indices` is empty in the loop of the `EpochParticipation()`, both `proposerRewardNumerator` and `proposerRewardDenominator` will be 0 and the returned error is nil. ```go=129 func EpochParticipation( beaconState state.BeaconState, indices []uint64, epochParticipation []byte, participatedFlags map[uint8]bool, totalBalance uint64, ) (uint64, uint64, []byte, error) { cfg := params.BeaconConfig() sourceFlagIndex := cfg.TimelySourceFlagIndex targetFlagIndex := cfg.TimelyTargetFlagIndex headFlagIndex := cfg.TimelyHeadFlagIndex proposerRewardNumerator := uint64(0) proposerRewardDenominator := uint64(0) for _, index := range indices { ... } return proposerRewardNumerator, proposerRewardDenominator, epochParticipation, nil } ``` In this case, error handling in lines 99-101 and 109-110 of the function `SetParticipationAndRewardProposer()` will be bypassed. ```go=84 func SetParticipationAndRewardProposer( ctx context.Context, beaconState state.BeaconState, targetEpoch primitives.Epoch, indices []uint64, participatedFlags map[uint8]bool, totalBalance uint64, ) (state.BeaconState, error) { var proposerRewardNumerator uint64 var proposerRewardDenominator uint64 currentEpoch := time.CurrentEpoch(beaconState) var stateErr error if targetEpoch == currentEpoch { stateErr = beaconState.ModifyCurrentParticipationBits(func(val []byte) ([]byte, error) { propRewardNum, propRewardDenom, epochParticipation, err := EpochParticipation(beaconState, indices, val, participatedFlags, totalBalance) if err != nil { return nil, err } proposerRewardNumerator = propRewardNum proposerRewardDenominator = propRewardDenom return epochParticipation, nil }) } else { stateErr = beaconState.ModifyPreviousParticipationBits(func(val []byte) ([]byte, error) { propRewardNum, propRewardDenom, epochParticipation, err := EpochParticipation(beaconState, indices, val, participatedFlags, totalBalance) if err != nil { return nil, err } proposerRewardNumerator = propRewardNum proposerRewardDenominator = propRewardDenom return epochParticipation, nil }) } if stateErr != nil { return nil, stateErr } if err := RewardProposer(ctx, beaconState, proposerRewardNumerator, proposerRewardDenominator); err != nil { return nil, err } return beaconState, nil } ``` In addition, the error handling in lines 117-119 will also be bypassed, allowing the function `RewardProposer()` with `proposerRewardDenominator` as 0 to be invoked in the function `SetParticipationAndRewardProposer()`. Therefore, the parameter `proposerRewardDenominator` passed in the `RewardProposer()` is 0.

Files: - `beacon-chain/core/blocks/activities.go` Commit: - [`3b8da2895d7067405b54c0829eee7e044a0f978e`](https://github.com/fastexlabs/bahamut-consensus/tree/3b8da2895d7067405b54c0829eee7e044a0f978e) The function `ProcessBlockActivities()` is intended to process the activities in a block, which invokes the function `ProcessActivity()` with each `activity` from the block. Since the activities are fetched from the execution layer, they could possibly contain some nil value. If the `activity` is nil, then fetching `ContractAddress` from the `activity` in line 42 of the function `ProcessActivity()` will lead to a runtime panic. ```go=34 func ProcessActivity( ctx context.Context, beaconState state.BeaconState, activity *ethpb.ActivityChange, ) (state.BeaconState, error) { ctx, span := trace.StartSpan(ctx, "core.ProcessActivtiyNoVerifySignature") defer span.End() contract := bytesutil.ToBytes20(activity.ContractAddress) idx, ok := beaconState.ValidatorIndexByContractAddress(contract) if !ok { nonStakersGas := beaconState.NonStakersGasPerEpoch() if err := beaconState.SetNonStakersGasPerEpoch(nonStakersGas + activity.DeltaActivity); err != nil { return nil, err } return beaconState, nil } ... ```

Files: - `beacon-chain/core/altair/reward.go` Commit: - [`3226f8330911cb8df77e775f0155b335ba771bd8`](https://github.com/fastexlabs/bahamut-consensus/tree/3226f8330911cb8df77e775f0155b335ba771bd8) - [`8198a02d28dee2b7485610279bcf24e4f0a2bf54`](https://github.com/fastexlabs/bahamut-consensus/commit/8198a02d28dee2b7485610279bcf24e4f0a2bf54) The fasttoken introduces a novel proposer base reward calculation based on the validator's power via the activity score associated with the validator's registered contracts. The function `BaseProposerReward()` is used to compute the base proposer reward defined in the whitepaper as follows: $$BPR = \frac{(A+T)*bf}{W * n * gwei},$$ where $A = \sum_{i=1}^{n} ea_i$ is the total effective activities of the $n$ validators and $T$ is the transaction constant gas in the window of 1575 epochs. The $bf$ is the base fee of the block and $W$ is the epoch window size 1575, $n$ is the number of validators and $gwei$ is the constant $10^9$. Therefore, the base proposer reward in each epoch is $BPR * s$, where $s$ (= 32) is the number of slots in an epoch. On the other hand, the total validator base reward per epoch is given by: $$BR_{total} = \frac{B*f}{\sqrt{B}} = f*\sqrt{B},$$ where $B$ is the total active balance, and $f$ is the constant 156 (according to the `config/params/mainnet_config.go` in the commit [`8198a02d28dee2b7485610279bcf24e4f0a2bf54`](https://github.com/fastexlabs/bahamut-consensus/commit/8198a02d28dee2b7485610279bcf24e4f0a2bf54)). Assume that the current number of validators is the target number 4096, and each of them has an effective balance of $8192 * 10^9$. Then the base reward is $$156 * \sqrt{4096 * 8192 * 10^9} = 0.9 * 10^9 gwei$$. According to the design, this reward will be distributed to the validators for attestation rewards and participating sync committees. In the Ethereum PoS, $1/7$ of the reward (i.e., $0.13 * 10^9$) is granted to the block proposers for proposing blocks. The fasttoken attempts to use the base proposer reward in each epoch (i.e., $32*BPR$) to replace the $1/7$ of the total validator base reward per epoch as the reward to the block proposers. In this case, assume that each block has a half load (15M gas consumed) and the base fee is $100 * gwei$, then the base proposer reward in each epoch is $$32 * \frac{(A+T)*bf}{W * n * gwei} = 32 * \frac{(32 *15M)* 100 * gwei}{4096 * gwei} = 0.395 * 10^9 gwei,$$ Therefore, the calculated reward is close to the value in the new design. However, in the implementation of the function `BaseProposerReward()`: ```go=65 func BaseProposerReward(s state.ReadOnlyBeaconState, totalPower, totalEffectivePower uint64) (uint64, error) { activity, err := helpers.TotalEffectiveActivity(s) if err != nil { return 0, errors.Wrap(err, "could not calculate total effective activity") } sharedActivity := s.SharedActivity() if sharedActivity == nil { return 0, errors.New("nil shared activity in state") } period := uint64(params.BeaconConfig().EpochsPerActivityPeriod) slotsPerEpoch := uint64(params.BeaconConfig().SlotsPerEpoch) denominator := period * period * slotsPerEpoch * slotsPerEpoch transactionsGas := sharedActivity.TransactionsGasPerPeriod baseFee := sharedActivity.BaseFeePerPeriod reward := baseFee * (activity + transactionsGas) / denominator if totalPower == 0 { return reward, nil } return reward * totalEffectivePower / totalPower, nil } ``` The reward does not align with the formula in the whitepaper as the reward is not divided by the number of active validators. Actually, the formula derived from the above code on average is as follows: $$ (A+T)*bf = 15 M * 100 gwei = 1.5 * 10^9 gwei$$.

Files: - `core/state/state_object.go` - `core/state_transition.go` Commit: - [`af75d5f6c6ab5a33f6a1ac86c5c443e7be943cf1`](https://github.com/fastexlabs/bahamut-execution/tree/af75d5f6c6ab5a33f6a1ac86c5c443e7be943cf1) There are no overflow and underflow protections in the following functions, making it possible for overflow/underflow to occur and could possibly lead to inaccurate calculations. **core/state/state_object.go** ```go=400 func (s *stateObject) AddActivity(amount uint64) { if amount == 0 { if s.empty() { s.touch() } return } s.SetActivity(s.Activity() + amount) } // SubActivity remove some amount of activity to s's activity func (s *stateObject) SubActivity(amount uint64) { if amount == 0 { if s.empty() { s.touch() } return } s.SetActivity(s.Activity() - amount) } ``` **core/state_transition.go** ```go=396 func (st *StateTransition) refundActivity(refund uint64) { if refund == 0 { return } totalRefund := refund totalActivityByContract := make(map[common.Address]uint64) totalRefundsByContracts := make(map[common.Address]uint64) currentActivities := st.state.GetCurrentActivities() for _, act := range currentActivities { totalActivityByContract[act.Address] += act.DeltaActivity } var proportion []float64 for _, act := range currentActivities { proportion = append(proportion, float64(act.DeltaActivity)/float64(totalActivityByContract[act.Address])) } for i, act := range currentActivities { if i == len(currentActivities)-1 { totalRefundsByContracts[act.Address] += refund act.DeltaActivity -= refund act.Activity -= totalRefundsByContracts[act.Address] st.state.SubActivity(act.Address, refund) log.Debug("Refunded contract activity", "activity", refund, "addr", act.Address) } else { totalRefundByContract := float64(totalRefund*st.state.GetRefundsByContract(act.Address)) / float64(st.state.GetRefund()) refundAct := uint64(totalRefundByContract * proportion[i]) totalRefundsByContracts[act.Address] += refundAct act.DeltaActivity -= refundAct act.Activity -= totalRefundsByContracts[act.Address] st.state.SubActivity(act.Address, refundAct) refund -= refundAct log.Debug("Refunded contract activity", "activity", totalRefundByContract, "addr", act.Address) } } } ```

Files: - `beacon-chain/rpc/prysm/v1alpha1/validator/proposer_bellatrix.go` Commit: - [`3226f8330911cb8df77e775f0155b335ba771bd8`](https://github.com/fastexlabs/bahamut-consensus/tree/3226f8330911cb8df77e775f0155b335ba771bd8) The function `unblindBuilderBlock()` retrieves the full payload block using the input blind block. However, the output block does not contain the fields `ActivityChanges`, `TransactionsCount`, `BaseFee`, And `ExecutionHeight`. ```go=306 Body: &ethpb.BeaconBlockBodyBellatrix{ RandaoReveal: psb.Block.Body.RandaoReveal, Eth1Data: psb.Block.Body.Eth1Data, Graffiti: psb.Block.Body.Graffiti, ProposerSlashings: psb.Block.Body.ProposerSlashings, AttesterSlashings: psb.Block.Body.AttesterSlashings, Attestations: psb.Block.Body.Attestations, Deposits: psb.Block.Body.Deposits, VoluntaryExits: psb.Block.Body.VoluntaryExits, SyncAggregate: agg, ExecutionPayload: pbPayload, }, ```