enable multi block per slot

[open-junius]

Description

When use the forge to deploy contract, I noticed there is a panic in runtime. the source code in pallet aura.
the error message is "Slot must increase". source code as follows:

error message

user@user-X870-EAGLE-WIFI7:~/github/tmp/collateral-contracts$ ./deploy.sh 
[⠊] Compiling...
No files changed, compilation skipped
Error: server returned an error response: error code -32603: Create pending runtime api error: Failed to call runtime API, Execution failed: Execution aborted due to trap: wasm trap: wasm `unreachable` instruction executed
WASM backtrace:
error while executing at wasm backtrace:
    0: 0x70a480 - node_subtensor_runtime.wasm!__rustc[5224e6b81cd82a8f]::rust_begin_unwind
    1: 0x29b6c - node_subtensor_runtime.wasm!core::panicking::panic_fmt::h4f1a54382be6d50f
    2: 0x2ea43f - node_subtensor_runtime.wasm!<pallet_aura::pallet::Pallet<T> as frame_support::traits::hooks::OnInitialize<<<<T as frame_system::pallet::Config>::Block as sp_runtime::traits::Block>::Header as sp_runtime::traits::Header>::Number>>::on_initialize::hb1215f7411744c05
    3: 0x583a3d - node_subtensor_runtime.wasm!<(TupleElement0,TupleElement1,TupleElement2,TupleElement3,TupleElement4,TupleElement5,TupleElement6,TupleElement7,TupleElement8,TupleElement9,TupleElement10,TupleElement11,TupleElement12,TupleElement13,TupleElement14,TupleElement15,TupleElement16,TupleElement17,TupleElement18,TupleElement19,TupleElement20,TupleElement21,TupleElement22,TupleElement23,TupleElement24,TupleElement25,TupleElement26) as frame_support::traits::hooks::OnInitialize<BlockNumber>>::on_initialize::h13ce7ae7c448e363
    4: 0x61154f - node_subtensor_runtime.wasm!frame_executive::Executive<System,Block,Context,UnsignedValidator,AllPalletsWithSystem,COnRuntimeUpgrade>::initialize_block::h02a0e55757ce5f00
    5: 0x417fc2 - node_subtensor_runtime.wasm!Core_initialize_block

pallet aura function

fn on_initialize(_: BlockNumberFor<T>) -> Weight {
			if let Some(new_slot) = Self::current_slot_from_digests() {
				let current_slot = CurrentSlot::<T>::get();
				if T::AllowMultipleBlocksPerSlot::get() {
					assert!(current_slot <= new_slot, "Slot must not decrease");
				} else {
					assert!(current_slot < new_slot, "Slot must increase");
				}

The client get the request for raw transaction, then try to initialize the runtime.
The new_slot is equal current_slot in on_initialize in aura pallet.

If we AllowMultipleBlocksPerSlot in runtime configuration, then everything is fine.
Contract deployment with forge is OK.

Related Issue(s)

• Closes Can't deploy contract with forge #2303

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Other (please describe):

Breaking Change

If this PR introduces a breaking change, please provide a detailed description of the impact and the migration path for existing applications.

Checklist

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have run ./scripts/fix_rust.sh to ensure my code is formatted and linted correctly
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

Screenshots (if applicable)

Please include any relevant screenshots or GIFs that demonstrate the changes made.

Additional Notes

Please provide any additional information or context that may be helpful for reviewers.

[shamil-gadelshin]

How exactly is this change connected to the original problem?

This is a non-trivial consensus setting. There are potential side effects, i.e, more potential forks and reorgs.

[open-junius]

How exactly is this change connected to the original problem?

This is a non-trivial consensus setting. There are potential side effects, i.e, more potential forks and reorgs.
Yes, it is small code change, but big impact. I will collect more comments from team. According to my research, the parameter just allow one node to produce the block again in the same slot.

[shamil-gadelshin]

Yes, it is small code change, but big impact. I will collect more comments from team. According to my research, the parameter just allow one node to produce the block again in the same slot.

What is the connection between a third-party "forge" app and "multiple blocks per slot" settings in Aura consensus? How exactly does it solve the problem? Probably, we miss a less intrusive way to achieve the same outcome.

[shamil-gadelshin]

Additionally, do you use fast-blocks when forge is failing?

[open-junius]

Additionally, do you use fast-blocks when forge is failing?
It is failed for both with fast-blocks and without fast-blocks.

[open-junius]

Yes, it is small code change, but big impact. I will collect more comments from team. According to my research, the parameter just allow one node to produce the block again in the same slot.

What is the connection between a third-party "forge" app and "multiple blocks per slot" settings in Aura consensus? How exactly does it solve the problem? Probably, we miss a less intrusive way to achieve the same outcome.

Via debugging, find out the root cause now.
For forge create a contract, it query the gas_estimation with the parameter Some(pending) of number_or_hash. Then frontier rpc client will build a pending_runtime_api, which call initialize_pending_block. It is failed when calling the on_initialize in Aura pallet.

I also tried hardhat, which use the number_or_hash as None to query gas_estimation. Then frontier use the latest_block_id, and use different api, as runtime_api without initialize_pending_block.

[shamil-gadelshin]

Via debugging, find out the root cause now.
For forge create a contract, it query the gas_estimation with the parameter Some(pending) of number_or_hash. Then frontier rpc client will build a pending_runtime_api, which call initialize_pending_block. It is failed when calling the on_initialize in Aura pallet.

I also tried hardhat, which use the number_or_hash as None to query gas_estimation. Then frontier use the latest_block_id, and use different api, as runtime_api without initialize_pending_block.

Thanks for the details! It seems from the code that Aura is not compatible with a notion of the "pending block" . I would wait for our Babe transition.

[open-junius]

Via debugging, find out the root cause now.
For forge create a contract, it query the gas_estimation with the parameter Some(pending) of number_or_hash. Then frontier rpc client will build a pending_runtime_api, which call initialize_pending_block. It is failed when calling the on_initialize in Aura pallet.

I also tried hardhat, which use the number_or_hash as None to query gas_estimation. Then frontier use the latest_block_id, and use different api, as runtime_api without initialize_pending_block.

Thanks for the details! It seems from the code that Aura is not compatible with a notion of the "pending block" . I would wait for our Babe transition.

I just found out the PR which introduced the error. will share info in team.

[liamaharon]

If this is a quirk needed for evm to work correctly I think it is fine. The nodes still enforce correct parent hashes, so I don't think will impact reorgs.

[shamil-gadelshin]

If this is a quirk needed for evm to work correctly I think it is fine. The nodes still enforce correct parent hashes, so I don't think will impact reorgs.

Did you have a chance to review why our update changed the default behaviour? @liamaharon

[liamaharon]

I spent quite some time trying to understand @shamil-gadelshin , but cannot find anything clear yet. My best guess at this time is it related to the frontier version bump we performed in that pr. I will continue investigating.

It may be worth reaching out to the maintainers of frontier about this if we have not already @open-junius , maybe they have encountered this before.