Feature Request

Implement the addDeclareTransaction endpoint

Describe Preferred Solution

The full node should forward the request to the sequencer and the

Endpoint

starknet_addDeclareTransaction

Params

• declare_transaction (required): The declare transaction.

Response

• transaction_hash: The hash of the declare transaction.
• class_hash: The hash of the declared class.

Error

• INVALID_CONTRACT_CLASS: The contract class is invalid.

Hi, I was looking to report a security issue I found with Papyrus. Your vulnerability disclosure readme points at github discussions and the starkware-libs github org which cannot be messaged.

I don't believe Papyrus is covered by Starkware's Immunefi program, so is there an email address/another contact method I can use?

Bug Report

Papyrus version:

21958c1

Current behavior:

2023-03-29T08:34:17.251346Z  INFO Added block 28610 with hash 0x015bb90f1789fce7dcf3e689a5ebe6fec549ffecd62de4088250da103d7a27e1.
2023-03-29T08:37:09.385193Z  INFO Added block 28611 with hash 0x0270ee0042508b7045e291ddd00008af9247033c1ba045f63d5d83e33a56be7f.
2023-03-29T08:40:43.229717Z  WARN data did not match any variant of untagged enum Transaction at line 1 column 1099
2023-03-29T08:40:54.580087Z  WARN unknown variant `StarkErrorCode.SCHEMA_VALIDATION_ERROR`, expected one of `StarknetErrorCode.BLOCK_NOT_FOUND`, `StarknetErrorCode.OUT_OF_RANGE_CLASS_HASH`, `StarkErrorCode.MALFORMED_REQUEST`, `StarknetErrorCode.UNDECLARED_CLASS` at line 1 column 49
2023-03-29T08:41:21.976325Z  WARN data did not match any variant of untagged enum Transaction at line 1 column 1099
2023-03-29T08:41:32.812513Z  WARN data did not match any variant of untagged enum Transaction at line 1 column 1099
2023-03-29T08:41:58.832765Z  WARN data did not match any variant of untagged enum Transaction at line 1 column 2008
2023-03-29T08:42:11.029753Z  WARN data did not match any variant of untagged enum Transaction at line 1 column 2008
2023-03-29T08:42:21.883737Z  WARN data did not match any variant of untagged enum Transaction at line 1 column 1099
2023-03-29T08:42:34.869916Z  WARN data did not match any variant of untagged enum Transaction at line 1 column 1099
2023-03-29T08:42:45.703701Z  WARN data did not match any variant of untagged enum Transaction at line 1 column 1099
2023-03-29T08:42:56.414124Z  WARN data did not match any variant of untagged enum Transaction at line 1 column 1099
2023-03-29T08:43:08.090133Z  WARN data did not match any variant of untagged enum Transaction at line 1 column 1099
2023-03-29T08:43:18.699454Z  WARN data did not match any variant of untagged enum Transaction at line 1 column 1099
2023-03-29T08:43:29.959032Z  WARN data did not match any variant of untagged enum Transaction at line 1 column 1099
2023-03-29T08:43:41.257672Z  WARN data did not match any variant of untagged enum Transaction at line 1 column 1099

Expected behavior:

To match StarkErrorCode.SCHEMA_VALIDATION_ERROR and handle it correctly

Steps to reproduce:

Related code:

/// Error codes returned by the starknet gateway.
#[derive(Copy, Clone, Debug, Deserialize, Serialize, Eq, PartialEq)]
pub enum StarknetErrorCode {
    #[serde(rename = "StarknetErrorCode.BLOCK_NOT_FOUND")]
    BlockNotFound = 0,
    #[serde(rename = "StarknetErrorCode.OUT_OF_RANGE_CLASS_HASH")]
    OutOfRangeClassHash = 26,
    #[serde(rename = "StarkErrorCode.MALFORMED_REQUEST")]
    MalformedRequest = 32,
    #[serde(rename = "StarknetErrorCode.UNDECLARED_CLASS")]
    UndeclaredClass = 44,
+   #[serde(rename = "StarknetErrorCode.SCHEMA_VALIDATION_ERROR")]
+   SchemaValidationError = ?,
}

Other information:

Feature Request

Implement the call endpoint

Describe Preferred Solution

The full node should execute the call and answer with the value

Endpoint

starknet_call

Params

• request (required): The details of the function call.
• block_id (required): The hash of the requested block, or number (height) of the requested block, or a block tag, for the block referencing the state or call the transaction on.

Response

• result: The function's return value, as defined in the Cairo output.

Error

• CONTRACT_NOT_FOUND: The contract was not found.
• INVALID_MESSAGE_SELECTOR: The message selector is invalid.
• INVALID_CALL_DATA: The call data is invalid.
• CONTRACT_ERROR: There was an error executing the contract.
• BLOCK_NOT_FOUND: The requested block was not found.

Bug Report

Papyrus version:

6ae90e2

Current behavior:

building docker file for MacM1 is returning error

executor failed running [/bin/sh -c rustup target add x86_64-unknown-linux-musl &&     CARGO_INCREMENTAL=0 cargo build  --target x86_64-unknown-linux-musl --release --package papyrus_node &&     CARGO_INCREMENTAL=0 cargo build   --target x86_64-unknown-linux-musl --release --package papyrus_load_test]: exit code: 137

Expected behavior:

Docker image should get created

Steps to reproduce:

Related code:

insert short code snippets here

Other information:

1. we need to use this specific commit version because we are on a custom app chain on starknet and we are getting issues related to 0x errors while trying with latest version / release tag
2. we are unable to build docker image for Mac M1 platform however able to run the node locally

Feature Request

Implement the addInvokeTransaction endpoint

Describe Preferred Solution

The full node should forward the request to the sequencer and the

Endpoint

starknet_addInvokeTransaction

Params

• invoke_transaction (required): The information needed to invoke the function.

Response

• transaction_hash: The hash of the declare transaction.

Feature Request

Implement the pendingTransactions endpoint

Describe Preferred Solution

The full node should send back its syncing status

Endpoint

starknet_pendingTransactions

Response

• result: An array of pending transactions.

UX report :

Memory actual usage for block synchronization is insane, around 2.3gb average.

1. Any idea what is causing this?
2. What are your final expectations for RAM usage for sync and after sync?

Bug Report

Papyrus version:

0.2.0-rc4

Current behavior:

While trying to call the aggregate function of a multicall contract deployed on mainnet : https://voyager.online/contract/0x01a87ac82de4c6e81dbfe5decf1f11d331366e1401e2b8e7ed342838ec49694f#readContract

Using papyrus it results in the following error : code: Unknown(-32602), message: "Invalid params" but it works using Alchemy.

Expected behavior:

It should return (block_number: u64, call_responses: Array<Span<felt252>>)

Steps to reproduce:

Using starknet-rs (latest version available on the repo) :

let calls: Vec<FieldElement> = vec![
        FieldElement::ONE, // size of the array of calls
        FieldElement::from_hex_be(
            "0x049d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7",
        )
        .unwrap(), // erc20 contract address
        selector!("balanceOf"),
        FieldElement::ONE, // size of the array
        FieldElement::from_hex_be(
            "0x061b6c0a78f9edf13cea17b50719f3344533fadd470b8cb29c2b4318014f52d3",
        )
        .unwrap(), // account address
    ];
    
    let provider = JsonRpcClient::new(HttpTransport::new(Url::parse(&conf.rpc.rpc_url).unwrap()));
    let call_result = provider
        .call(
            FunctionCall {
                contract_address: FieldElement::from_hex_be(
                    "0x01a87ac82de4c6e81dbfe5decf1f11d331366e1401e2b8e7ed342838ec49694f"
                ).unwrap(),
                entry_point_selector: selector!("aggregate"),
                calldata: calls,
            },
            BlockId::Tag(BlockTag::Latest),
        )
        .await;
    match call_result {
         Ok(result) => result,
        Err(e) => {
             println!("Error calling contract: {:?}", e);
             vec![]
        }
     }
        

Bug Report

Papyrus version:

0.2.0-rc3

Current behavior:

Hey there,

I've been trying to deploy two nodes for our backends: rpc.starknet.id and goerli.rpc.starknet.id. Unfortunately I have trouble to specify on which chain papyrus should start (goerli or mainnet).

I created a docker-compose.yml for both and specified the correct ethereum RPC (mainnet or goerli), but I have two issues:

• The goerli deployment replies with chain_id 0x534e5f4d41494e which is SN_MAIN instead of SN_GOERLI. mainnet too but it's expected
• The mainnet deployment replies with the block amount of goerli:

curl --header 'Content-Type: application/json' \
 --data '{"jsonrpc":"2.0","id":0,"method":"starknet_blockHashAndNumber"}' 'https://goerli.rpc.starknet.id/rpc/v0_4'
{"jsonrpc":"2.0","result":{"block_hash":"0x60c75a570a6755a181ce9b870407478ec0105baf3cc0586b605626b105d87c1","block_number":416990},"id":0}

416990 is the amount of blocks on goerli, mainnet is far behind
I am not sure to understand what caused this. Any help is welcomed.

Steps to reproduce:

Start with my docker-compose.yml (update your ethereum rpc). sudo docker-compose up --build

Other information:

I wanted to open a discussion because I am not sure it is a bug, I think it is probably just an issue on my configuration, but I didn't have permission to create a new post in Discussions.

Issue occured after I update the node. Update procedure:

• Stop the node
• git checkout main
• git pull
• cargo run --release --package papyrus_node --bin papyrus_node

Output:

thread 'tokio-runtime-worker' panicked at 'Missing header for block {block_number}.', crates/papyrus_storage/src/header.rs:105:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: task 13 panicked

I think I broke the db because If I start with fresh db node starts up.

Interested in participating, rust lovers

Bug Report

Papyrus version:

Latest Release
sha256:0f29a084003b9d05ba28b44f6ac9ada10c3604b10bc55d36f04e72b56d379071

Current behavior:

RPC is not responding

curl: (52) Empty reply from server

Expected behavior:

RPC should return some response other then empty

Steps to reproduce:

docker run --rm --name papyrus\
  -p 8080-8081:8080-8081 \
  -v /<local-host-data-path>:/app/data \
  --memory 1g
  ghcr.io/starkware-libs/papyrus:latest \
  --base_layer.node_url <ethereum_node_url> \
  --user "$(id -u):$(id -g)"

curl --location 'localhost:8080/rpc/v0_4_0' --header 'Content-Type: application/json'\
 --data '\{"jsonrpc":"2.0","id":0,"method":"starknet_getBlockTransactionCount", "params": [{"block_number": 100000}] }'
 curl: (52) Empty reply from server

Feature Request

Implement the addDeployAccountTransaction endpoint

Describe Preferred Solution

The full node should forward the request to the sequencer and the

Endpoint

starknet_addDeployAccountTransaction

Params

• deploy_account_transaction (required): The deploy account transaction.

Response

• transaction_hash: The hash of the declare transaction.
• account_address: The address of the new account.

Error

• INVALID_ACCOUNT_CLASS: The account class is invalid.

Feature Request

Describe the Feature Request

When I try to call this RPC on my own, I get a CORS error. Would it be possible to configure CORS in Papyrus?

Feature Request

Implement the estimateFee endpoint

Describe Preferred Solution

The full node should forward the request to the sequencer

Endpoint

starknet_estimateFee

Params

• request (required): The transaction to estimate.
• block_id (required): The hash of the requested block, or number (height) of the requested block, or a block tag, for the block referencing the state or call the transaction on.

Response

• result: The fee estimation.

Error

• CONTRACT_NOT_FOUND: The contract was not found.

Objective

Add a user agent that includes the Papyrus version (currently hard-coded 'pre-release') and the OS as part of the HTTP requests.

Feature Request

Would love the StarkNet community and Starkware team to provide more color on what type of hardware / bandwidth needs are needed to run this full node effectively, particularly under various scenarios of onchain activity. Do I need a bare metal data center? Generic Kubernetes cluster/public managed cloud services? Custom hardware? My normal everyday laptop? etc

Describe Alternatives

One "alternative" may just be to continuously collect and sample full node runners on StarkNet what their exact setup is, costs associated etc. This would be extremely helpful data to inform who can / can't afford or have the know-how on how to run these nodes. Particularly, if this needs to run on non-standard, non-consumer grade hardware (which it seems like it might if there's a lot of onchain activity).

Related Code

N/A

Additional Context

ethereum.org and mainnet EL/CL teams have decent documentation around what running various node setups require. I believe the Rocket Pool / Dappnode (solo-staker) community has generated good documentation for L1 mainnet and have some degree of consensus on agreed-upon, efficient, somewhat cost-effective setups. Perhaps we look to those communities for assistance and inspiration.

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

Feature Request

The readme file for the full node software indicates that this is under "MIT" but the LICENSE file is for Apache. Which one is it?

I am not sure what licensing this is under but would be good to get consistency on what is allowed vs. not-allowed with this repo.

Please pick Apache or MIT and make sure that is consistent across readme + LICENSE file.

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

When adding a new config, it's necessary to edit several places: default value (see default config building), file configuration, CLI configuration, and in the future env configuration.

Objective

This issue aims to design an architecture that will allow editing and adding new configs in one place only in which the configuration metadata is defined (something like name, type, description, and default value) and let everything else be derived from that. The design could be submitted either as a chart or a code draft.
This issue will be followed by the issue of implementing the approved design.

Acceptance Criteria

• One source of truth for config parameters that derive all other config files. The design will be reviewed by Papyrus core developers.

Bug Report

Papyrus version:

Current behavior:

Node fully syncs and is stable via Docker but get the following error if attempting to run via the compile and run method.

$ cargo run --release --package papyrus_node --bin papyrus_node
    Finished release [optimized] target(s) in 0.88s
     Running target/release/papyrus_node
2023-01-16 10:56:33.213 INFO papyrus_node - Booting up.
Error: No such file or directory

This happens on a fresh install and when the node is fully synced via Docker.

Expected behavior:

Node to run.

Steps to reproduce:

Follow 'Getting Started' in the readme

Related code:

insert short code snippets here

Other information:

May well be user error.

This is on a Lenovo M73 Tiny with i3, 8gb RAM and a 500gb SSD. Running Ubuntu 22.04.

Feature Request

Describe the Feature Request

It could be great to be able to use papyrus_common inside our projects to benefit some already implemented and tested computation like hashes.
Or is there a specific reason to not expose it?

Describe Preferred Solution

Would be great to be able to do:

papyrus_common = { git = ".../papyrus", tag = "v0.1.3-alpha" }

Related Code

members = [
    "crates/papyrus_common",
    ...
]

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

The reported issue involves building a Docker image for the Papyrus version 6ae90e2 on a Mac M1 platform, resulting in an exit code 137. To resolve this, it is suggested to check and adjust resource allocations in Docker settings, ensure correct configurations for Rustup and Cargo targeting the x86_64-unknown-linux-musl platform, review the Dockerfile for proper architecture specifications, and consider using Docker Buildx for multi-platform support. Additionally, investigating commit-specific changes and seeking community support for the Papyrus project may provide insights into resolving the issue.

Feature Request

Implement the syncing endpoint

Describe Preferred Solution

The full node should send back its syncing status

Endpoint

starknet_syncing

Response

• syncing: The state of the synchronization, or false if the node is not synchronizing.

In the existing codebase, there are many structures used in many libraries of the project, which are almost the same or the same. For example there is a structure for DeployTransaction in starknet_client and in starknet_api. Is it possible to separate all the structures in one place, e.g. starknet_api add use cargo features to specify which parts of the crate to be included.