Description

As part of the effort trying to reduce the build time we might consider swapping some heavy dependencies.

Let's try to use pico-args instead of clap.

Description

Add some syntactic sugar for logging for pallet-starknet.

Description

Implement the validation logic for Starknet transactions. This logic must be compatible with how account abstraction works on Starknet.

Validation of transaction is performed via TaggedTransactionQueue trait, in validate_transaction.

We need to implement this trait and configure the runtime.

Resources

• Substrate transaction lifecycle
• Starknet Account Abstraction

Description

Currently, hardcoded Cairo program is run when execute_cairo_assembly_program extrinsic is triggered.

We need to execute actual deployed Cairo program.

Need to think about how to pass the entrypoint (user input ?).

Description

https://github.com/paritytech/frontier

Description

Implement benchmark in CI and upload results as artifacts.

A patch was summited for librocksdb-sys to enable rustc_codegen_cranelift compilation.
However the version used as a dependency on this project is older so we created a new fork of the specific version needed with the cranelift patch in this repo.
When the rocksdb version that is compatible with rustc_codegen_cranelift is being used by default we can remove the patch version from the Cargo file.

Description

Implement the required substrate pallet hooks for Starknet pallet.

The list of possible hooks are defined here.

We need to identify which ones we have to implement.

Make https://github.com/lambdaclass/starknet_in_rust no_std compatible

See: https://endler.dev/2020/rust-compile-times/#use-cargo-nextest-for-faster-test-execution

Use https://nexte.st/ for tests and integrate in the CI: https://nexte.st/book/pre-built-binaries.html#using-pre-built-binaries-in-ci

Description

Remove cairo pallet.

Feature Request

Describe the Feature Request

Contract Address should be computed on the fly when submitting a deploy transaction based.

Related Code

https://docs.starknet.io/documentation/architecture_and_concepts/Contracts/contract-address/

Additional Context

If the feature request is approved, would you be willing to submit a PR?
(Help can be provided if you need assistance submitting a PR)

• Yes
• No

Description

Implement a PoC to enable autonomous smart contracts execution.

ansi_term is Unmaintained

The maintainer has advised that this crate is deprecated and will not receive any maintenance.

The crate does not seem to have much dependencies and may or may not be ok to use as-is.

Last release seems to have been three years ago.

Possible Alternative(s)

The below list has not been vetted in any way and may or may not contain alternatives;

• anstyle
• console
• nu-ansi-term
• owo-colors
• stylish
• yansi

Dependency Specific Migration(s)

• structopt, clap2

See advisory page for additional details.

Description

As part of the effort of trying to reduce the build time we might consider replacing serde by nanoserde.

https://github.com/not-fl3/nanoserde

Feature Request

Describe the Feature Request

We want to have some kind of faucet extrinsic for an address to get some ETH.

Describe Preferred Solution

This should modify the StorageView starknet's pallet storage map.

Describe Alternatives

Related Code

Additional Context

If the feature request is approved, would you be willing to submit a PR?
(Help can be provided if you need assistance submitting a PR)

• Yes
• No

Description

Starknet is decentralizing both the network and the governance of the protocol.

We should investigate if we could use some advanced governance features (like OpenGov, Pallet democracy) from substrate to achieve this.

We need to sync with the governance committee (@Manorsw @devenmatthews @s0lness) and with @bbrandtom about the plans and what features could be useful for them and the governance of Starknet.

Resources

• OpenGov
• Participating in Democracy
• Pallet democracy
• Starknet foundation delegation for the first vote
• Delegate profile thread

Description

Build is currently quite slow, mainly due because of a large number of dependencies.

We should investigate if we can improve build time. Some tips from this article can be applied.

Feature Request

Describe the Feature Request

We should compute the state diff after invoke and deploy transactions.
The state trie should also be updated after declare and deploy transactions.

Describe Preferred Solution

• This involves writing wrappers for some starknet-api structs.
• Then the StorageView mapping in the starknet pallet should be adequately updated.

Related Code

https://github.com/starkware-libs/starknet-api/blob/main/src/state.rs#L21

Additional Context

• https://docs.starknet.io/documentation/architecture_and_concepts/Data_Availability/on-chain-data/#v0.11.0_format
• https://david-barreto.com/starknets-architecture-review/

If the feature request is approved, would you be willing to submit a PR?
(Help can be provided if you need assistance submitting a PR)

• Yes
• No

Resources

• Starknet Decentralized Protocol I - Introduction
• Starknet Decentralized Protocol II - Candidate for Leader Elections
• Starknet Decentralized Protocol III - Consensus
• Starknet Decentralized Protocol IV - Proofs in the Protocol
• Starknet Decentralized Protocol V - Checkpoints for Fast Finality
• Starknet Decentralized Protocol VI - The Buffer Problem
• Starknet Decentralized Protocol VII - Chained Proof Protocols & Braiding

Description

Starknet allows to send messages from Ethereum to Starknet. In order to do that a transaction has to be sent on Ethereum to a specific smart contract. Once the tx is final the sequencer consumes the message on Starknet and executes the transaction.

Acceptance criteria

• The sequencer can pick up final messages
• The sequencer can execute those messages

Description

Fix relevant cargo clippy warnings.

Crate parity-wasm deprecated by the author

This PR explicitly deprecates parity-wasm.
The author recommends switching to wasm-tools.

See advisory page for additional details.

mach is unmaintained

Last release was almost 4 years ago.

Maintainer(s) seem to be completely unreachable.

Possible Alternative(s)

These may or may not be suitable alternatives and have not been vetted in any way;

• mach2 - direct fork

See advisory page for additional details.

See: https://endler.dev/2020/rust-compile-times/#disable-unused-features-of-crate-dependencies

Description

Setup a complete testnet infrastructure including:

• configuration & deployment scripts (terraform, kubernetes)
• comprehensive documentation and instructions on how to join the testnet

Potential segfault in the time crate

Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

The affected functions from time 0.2.7 through 0.2.22 are:

• time::UtcOffset::local_offset_at
• time::UtcOffset::try_local_offset_at
• time::UtcOffset::current_local_offset
• time::UtcOffset::try_current_local_offset
• time::OffsetDateTime::now_local
• time::OffsetDateTime::try_now_local

The affected functions in time 0.1 (all versions) are:

• at
• at_utc
• now

Non-Unix targets (including Windows and wasm) are unaffected.

Patches

Pending a proper fix, the internal method that determines the local offset has been modified to always return None on the affected operating systems. This has the effect of returning an Err on the try_* methods and UTC on the non-try_* methods.

Users and library authors with time in their dependency tree should perform cargo update, which will pull in the updated, unaffected code.

Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series.

Workarounds

A possible workaround for crates affected through the transitive dependency in chrono, is to avoid using the default oldtime feature dependency of the chrono crate by disabling its default-features and manually specifying the required features instead.

Examples:

Cargo.toml:

chrono = { version = "0.4", default-features = false, features = ["serde"] }

chrono = { version = "0.4.22", default-features = false, features = ["clock"] }

Commandline:

cargo add chrono --no-default-features -F clock

Sources:

• chronotope/chrono#602 (comment)
• vityafx/serde-aux#21

See advisory page for additional details.

Description

We need to handle $STRK token as the native asset of the chain. The particularity is that this token is actually an ERC20 token and not a native asset. Hence we need to determine the impact on substrate architecture. The main immediate impact is the handling of transaction fees.
We should also investigate how to handle some pallets that could require to manipulate the $STRK token, for example staking, governance pallets.

Acceptance criteria

• The address of the $STRK token must be configurable at the pallet level.
• Transaction fees must be paid in $STRK tokens

Resources

• Fee mechanism on Starknet

Description

Offchain worker needs to access Ethereum data, hence it requires the address of an Ethereum RPC node. We want this address to be configurable.
We won't be able to have access to env variables or config file values from the outer node in the runtime or in the pallet.
We probably will need to use offchain storage to deal with configuration.

Start by implementing a single config variable: eth_execution_api_rpc_url.

Resources

• Layered configuration system for Rust applications (with strong support for 12-factor applications).
• Offchain worker fetch price example
• Offchain local storage doc
• Offchain local storage example
• OffchainStorage trait doc

Description

With Substrate, we need to determine the weight (cost) for externally callable functions.

See:

• https://docs.substrate.io/test/benchmark/
• https://docs.substrate.io/build/tx-weights-fees/

We need to implement proper benchmarks in order to determine those fees.

See: https://endler.dev/2020/rust-compile-times/#cranelift-the-alternative-rust-compiler

Use prebuilt binaries for Github actions: https://github.com/bjorn3/rustc_codegen_cranelift/actions?query=branch%3Amaster+event%3Apush+is%3Asuccess

Make https://github.com/lambdaclass/cairo-rs no_std compatible

Description

Implement the RPC server to query the Starknet wrapped blocks.

See:

• frontier
• moonbeam

See also this issue: #20

Feature Request

Describe the Feature Request

Implement Declare Transactions

Describe Preferred Solution

Describe Alternatives

Related Code

Additional Context

If the feature request is approved, would you be willing to submit a PR?
(Help can be provided if you need assistance submitting a PR)

• Yes
• No

Description

Implement support of autonomous smart contract for custom starknet.

Resources

• https://github.com/mikasa-ack/mikasa-node

Description

Implement a wrapper type for the cairo-vm felt representation.

Add this Felt type in primitives/starnet crate, in a types module.

Description

We don't want to discover that a tx doesn't pass the validation step when we're construction the block it's an unnecessary waste of time and resources so we need to verify that a tx is valid when adding it to the mempool.

Acceptance criteria

• Invalid (__validate__ fails) transactions are not added in the mempool

Description

We need to do some research work and implement Narwhal & Bullshark consensus as a substrate consensus client and perform some benchmarks.

Resources

• Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus
• Bullshark: DAG BFT Protocols Made Practical
• Narwal Rust implementation in Sui

See xJonathanLEI/starknet-rs#303 for more context

Descripion

We need to change the default block header structure used in substrate and define one compatible with Starknet.
We will create a BlockHeader types in primitives/starknet and add some unused fields for now.

The structure of Starknet block header is defined here: https://docs.starknet.io/documentation/architecture_and_concepts/Blocks/header/

Strategies

Inherent transactions

https://docs.substrate.io/fundamentals/transaction-types/

Inherent transactions—sometimes referred to as inherents—are a special type of unsigned transaction. With this type of transaction, block authoring nodes can add information directly to a block. Inherent transactions can only be inserted into a block by the block authoring node that calls them.

Pros

• Seems to be quite easy and without a lof of implications

Cons

• Performance overhead ?

Wrapper block

https://corepaper.org/substrate/wrapper/
https://substrate.stackexchange.com/a/2648

Pros

• Seems to be the easiest approach, without changes to core substrate features

Cons

• Performance overhead, would be cool to be able to estimate the overhead

Extend substrate primitives

Pros

• Might be the most performant approach

Cons

• Touches core substrate features and might have a lot of implications

Projects

Moonbeam

Moonbeam is using the wrapper block strategy

Feature Request

Describe the Feature Request

Implement Deploy Transaction

Describe Preferred Solution

Describe Alternatives

Related Code

Additional Context

If the feature request is approved, would you be willing to submit a PR?
(Help can be provided if you need assistance submitting a PR)

• Yes
• No

aesni has been merged into the aes crate

Please use the aes crate going forward. The new repository location is at:

<https://github.com/RustCrypto/block-ciphers/tree/master/aes>

AES-NI is now autodetected at runtime on i686/x86-64 platforms.
If AES-NI is not present, the aes crate will fallback to a constant-time
portable software implementation.

To prevent this fallback (and have absence of AES-NI result in an illegal
instruction crash instead), continue to pass the same RUSTFLAGS which were
previously required for the aesni crate to compile:

RUSTFLAGS=-Ctarget-feature=+aes,+ssse3

See advisory page for additional details.

Description

Currently, we cannot set the timestamp in tests using pallet-timestamp.

aes-soft has been merged into the aes crate

Please use the aes crate going forward. The new repository location is at:

<https://github.com/RustCrypto/block-ciphers/tree/master/aes>

AES-NI is now autodetected at runtime on i686/x86-64 platforms.
If AES-NI is not present, the aes crate will fallback to a constant-time
portable software implementation.

To force the use of a constant-time portable implementation on these platforms,
even if AES-NI is available, use the new force-soft feature of the aes
crate to disable autodetection.

See advisory page for additional details.