nethermindeth / juno Goto Github PK

Auto deploy docusaurus docs to github pages.

Is your feature request related to a problem? Please describe.
The project does not have a description. This is especially good for people who see this repo for the first time. Also, this can help us to take on the community standards

Describe the solution you'd like
Add a concise description summarizing the project

Is your feature request related to a problem? Please describe.
Currently, in the creation of a new config we use only default paths.

Describe the solution you'd like
Create a flag in the commands where you could select a place to read and save your data and configs.

For example here we should add a flag where the default value is the pre-set path to the config.

Create StarkNet account management / signing developer wallet so early users can create accounts for interacting with StarkNet easily.

Add mdbx for key-value storage

• https://go.dev/blog/godoc
• https://go.dev/doc/effective_go#commentary
• https://github.com/golang/proposal/blob/master/design/51082-godocfmt.md

https://starknet.io/documentation/transaction-structure-and-hash/

SIGNATURES
While StarkNet does not have a specific signature scheme built into the protocol, the Cairo language in which smart contracts are written does have an efficient implementation for ECDSA signature with respect to a STARK-friendly curve.

The STARK-friendly curve lives in F2p with p=2251 + 17 · 2192 + 1 , and is defined by:

y2= x3 + α · x + β

Where:

α= 1

β=3141592653589793238462643383279502884197169399375105820974944592307816406665
And the generator used in the ECDSA algorithm is G=gx, gy where:

gx=874739451078007766457464989774322083649278607533249481151382481072868806602
gy=152666792071518830868575557812948353041420400780739481342941381225525861407

For more details see our repo.

Is your feature request related to a problem? Please describe.
Each time a new contributor arrives at our project, and creates a new issue or submits a new PR, we should create a welcome message for them.

Describe the solution you'd like
Add a github action like this or this

Is your feature request related to a problem? Please describe.
We want to work as a middleware between Starknet Gateway and Voyager,

Describe the solution you'd like
Take a look to docs for details about how should be implemented this feature

There are dependabot alerts on beta.6

In the repository

Add contract address calculation as specified in: https://starknet.io/documentation/contracts/

CONTRACTS ADDRESSES
The contract address is a unique identifier of the contract on Starknet. It is a hash chain of the following information:

Prefix.
Caller address.
Salt. In StarkNet alpha this is a random value given by the sequencer
Contract hash
Constructor call data hash

Specifically, it is calculated as follows:

contract_address := pedersen(
“STARKNET_CONTRACT_ADDRESS”,
caller_address,
salt,
pedersen(contract_code),
pedersen(constructor_calldata))
Where:

pedersen is a Pedersen hash function applied to a list of elements.
“STARKNET_CONTRACT_ADDRESS” is a constant prefix encoded into bytes (ASCII) using big endian encoding.
See the address computation here.

https://starknet.io/documentation/starkgate-token-bridge/

STARKGATE – TOKEN BRIDGE
PAGE CONTENT:
StarkGate General Architecture – Go
Transfer L1→L2 – Go
Transfer L2→L1 – Go
STARKGATE GENERAL ARCHITECTURE
On Ethereum, we have uploaded bridges that handle a single token type on L2 (i.e., there is a separate deployment for every token type). These bridges communicate with their counterpart on StarkNet.

The bridges facilitate a user’s ability to conduct their transactions with their ETH and ERC-20 tokens that reside on L1, via the StarkNet Alpha network and its STARK-based computational compression capabilities. For simplicity, we use terms such as “deposit”, “transact”, and “transfer” to refer to various operations involving a bridge, even though ETH and ERC20 tokens never actually leave Ethereum.

TRANSFER L1→L2
STEP 1: CALL THE DEPOSIT FUNCTION ON L1
The user calls the function deposit, supplying as parameters the recipient address on StarkNet (uint256 number which is <= StarkNet’s Prime) and the amount to transfer in the case of ERC-20 token. The deposit function then:

Checks that the funds transferred are within the Alpha limitation
Transfers the funds from the user account to the StarkNet bridge
Emits a deposit event with the sender address on L1, the recipient address on L2, and the amount
Sends a message to the relevant L2 bridge with the amount to be transferred, and the recipient address as parameters. Notice that, since every single bridge is dedicated to one token type, the token type isn’t needed to be explicit here.
At the end of this step (i.e., after the execution on L1) the deposit tx is known to StarkNet’s gateway, yet sequencers may wait for enough L1 confirmations before the deposit is included. Until the progression for the next step occurs, the tx status for StarkNet remains as “NOT RECEIVED”.

STEP 2: DEPOSIT TRIGGERED ON STARKNET
Once enough block confirmations are received for step 1, the sequencers may refer to the deposit request by triggering the function “handle_deposit”. The function handle_deposit verifies that the deposit came from the correct bridge on L1. It then calls to the relevant ERC-20 contract (even ETH on StarkNet is treated as a type of ERC-20) and mints the tokens for the user.

At the end of this step (i.e., after the tx on StarkNet is sequenced, but before a proof is generated), the status of the deposit request will be “ACCEPTED_ON_L2”.

STEP 3: THE BATCH THAT INCLUDES THE TRANSFER IS PROVED
After enough txs are aggregated (or enough time passes), StarkNet’s provers will prove the validity of the batch and submit a state update to L1. Once this happens, the message confirming the funds’ transfer will be cleared from the StarkNet Core Contract, and the fact that the user has transferred their funds will be part of the now finalized state of StarkNet. Note that if the message wasn’t on L1 to begin with (meaning StarkNet “invented” a deposit request), the state update would fail.

TRANSFER L2→L1
STEP 1: CALL THE WITHDRAW FUNCTION ON L1
The user calls the function initiate_withdraw, supplying as parameters the recipient address on Ethereum, as well as the amount to transfer (Uint256). The withdraw function then:

Burns the transferred amount of tokens from the balance of the withdrawal’s initiator
Sends a message to the relevant L1 bridge with the amount to be transferred, and the recipient address as parameters. Notice that since every single bridge takes care of one token type, the token type isn’t needed to be explicit here.

STEP 2: THE BATCH THAT INCLUDES THE TRANSFER IS PROVED
After enough txs are aggregated (or enough time passes), StarkNet’s provers will prove the validity of the batch and submit a state update to L1. Once this happens, the message from the previous step is stored in the StarkNet Core Contract.

Note that with the introduction of contract classes as of 0.9.0, deploy may be deprecated. See this post for details.

It should be possible to build and deploy Solidity contracts to StarkNet by integrating with Warp tools.
https://github.com/NethermindEth/warp

Is your feature request related to a problem? Please describe.
The modules of the project contain and need some configurations, that now are hard-coded, but in some cases, we need to load this config when the app starts.

Describe the solution you'd like
Add cobra and viper, the first for the handling of flags and the second for the handling of configuration files

See #92.

• starknet_getEvents
• starknet_getStateUpdateByHash

Add contract hash calculator (not contract address hash) as specified in: https://starknet.io/documentation/contracts/

CONTRACT HASH
The contract hash is a hash of its definition. The elements defining a contract are:

API version (the version under which the contract was deployed)
Array of external functions entry points
Array of L1 handlers entry points1
Array of constructors entry points (currently the compiler allows only one constructor)
Array of used builtin names2 (ordered by declaration)
Keccak3 of the contract’s program. Here the contract’s program stands for the json obtained by executing starknet-compile with the --ne_debug_info flag. To see the exact computation of this field, see our repo.
Bytecode (represented by an array of field elements)
The contract’s hash is the chain hash4 of the above, computed as follows:

start with h(0,api_version)
for every line in the above (excluding the first), compute:
h(h(previous_line), new_line)

the hash of an array a[1],…,a[n] is defined by
h(...h(h(0,a[1)),a[2]),...,a[n]),n)

let c denote the cumulative hash resulting from applying the above process, the contract’s hash is then h(c, number_of_lines), where number_of_lines is 7.
For more details, see the Cairo implementation here.

Add block hash calculation:

BLOCK HASH
A block hash is a hash of the block’s header elements.

Specifically:

pedersen_hash(
parent_block_hash,block_number,
new_global_root,sequencer,
creation_time, transaction_commitment, transaction_count
event_commitment, event_count, protocol_version,
extra_data
)
In StarkNet Alpha, each component that is not yet implemented is replaced with 0.

The code for the block hash generation can be found here.

Get Started

• with Go
• with contributing to Juno
• with contributing to Juno docs

Create a data fetcher (logs fetcher) for L1 via a link to JSON RPC endpoint (local node or Infura/Alchemy like provider)

https://starknet.io/documentation/l1-l2-messaging/

https://github.com/OpenZeppelin/nile

Merkle-Patricia tree

As mentioned above, our commitment scheme uses a binary Merkle-Patricia tree with the Pedersen hash function. Each node in the tree is represented by a triplet (length, path, bottom). The actual data is placed in the leaves, and a leaf node with data x is encoded by the triplet (0,0,x). Empty nodes (leaves or internal) are encoded by the zero triplet (0,0,0). A subtree rooted at a node (length, path, bottom) contains a non empty node only at the subtree obtained by following the path specified by path.  path is an integer in [0, 2^length-1], and the binary expansion of path indicates how should we proceed along the tree, where the first step is indicated by the most significant bit, and 0,1 are interpreted as left, right correspondingly. Note that the reason that length is specified and cannot be deduced from path is that we’re dealing with field elements of fixed size (251 bits each).

The following rules specify how the tree is constructed from a given set of leaves:

The hash of a node N =(length, path, bottom), denoted by H(N), is:

• bottom if length = 0
• h(bottom, path) + length otherwise (note that all arithmetic operations are done in our field)

The value of a node whose children are  left=(length_l, path_l, bottom_l), right=(length_r, path_r, bottom_r) is:

• (0,0,0) if both left and right are empty
• (left_l + 1, path_l, left.bottom) if right is empty
• (length_r + 1, path_r + 2^length_r, right.bottom) if left is empty
• (0, 0, h(H(left), H(right))) otherwise

We now show an example of the construction of a height 3 Merkle-Patricia tree from the leaves [0,0,1,0,0,1,0,0]:

Where r=h(H(2,2,1),H((2,1,1)). Note that in our example there is no skipping from the root (length is zero), so the final commitment to the tree will be H((0,0,r))=r.

Suppose that we want to prove, with respect to the commitment we have just computed, that the value of the leaf whose path is given by 101 is 1. In a standard Merkle tree, the proof would have consisted of data from three nodes (siblings along the path to the root). Here, since the tree is sparse, we only need to send the two children of the root (2,2,1), (2,1,1). This suffices to reproduce the commitment r, and since the height of the tree, 3, is known and fixed, we know that the path 01 of length 2 specified by the right child (2,1,1) leads us to the desired leaf.

https://github.com/argentlabs/argent-x

• Receive and propagate:

  • State diffs.
  • Transactions.
  • Events.

• Send state to new syncing nodes.

Add logging for the execution of the program, add some levels of logs

Maybe worth to take a look here, the best I think are distillog or glog

https://starknet.io/documentation/events/

EVENTS
A contract may emit events throughout its execution. Each event contains the following fields:

from_address: address of the contract emitting the events
keys: a list of field elements
data: a list of field elements
Keys are fields that can be used for indexing the events, while the data may contain any information that we wish to log (note that we are dealing with two separate lists of possibly varying size, rather than a list of key-value pairs).

EMITTING EVENTS
Events can be defined in a contract using the @event decorator. Once an event E has been defined, the compiler automatically adds the function E.emit(). The following example illustrates how an event is
defined and then emitted:

@event
func message_received(a : felt, b: felt):
end

message_received.emit(1,2)
The emit function emits an event with a single key, which is an identifier of the event, given by sn_keccak(event_name), where event_name is the ASCII encoding of the event’s name. To emit custom keys, one should use the low level emit_event system call, which takes an array of keys and an array of data as input.

Note that the emit function may take structs or arrays (with an adjacent parameter indicating the array’s length) as arguments, which will be flattened into a single array of felts.

The emitted events are part of the transaction receipt.

EVENT ABI
The event definition appears in the contract’s ABI. It contains the list of data fields (name and type) and the list of the custom keys (that is, all keys except the event identifier discussed above). Below is an example of an event inside the ABI:

{
"data": [
{
"name": "a",
"type": "felt"
},
{
"name": "b",
"type": "felt"
}
],
"keys": [],
"name": "message_received",
"type": "event"
}
EVENT HASH
The event hash is given by:
h(h(h(h(0,from_address),keys_hash),data_hash),3)

Where:
keys_hash, data_hash are the hashes of the keys list and data list correspondingly.

The hash of an array of n elements is given by:
h(...h(h(0,a[1)),a[2]),...,a[n]),n)
h is the pedersen hash function

The event hashes are eventually included in the event_commitment field of a block.

Add code coverage metrics to the repository so we can track test coverage from the early stages of the project
https://about.codecov.io/blog/getting-started-with-code-coverage-for-golang/

Specification.

• starknet_getStorageAt
• starknet_getCode
• starknet_call

Get block.

• starknet_getBlockByHash
• starknet_getBlockByNumber
• starknet_getTransactionsByHash
• starknet_getTransactionsByHashAndIndex
• starknet_getTransactionsByBlockNumberAndIndex

Pending block in.

• starknet_getBlockByNumber
• starknet_getTransactionByBlockNumberAndIndex
• starknet_getStorageAt
• starknet_getStorageAt
• starknet_getCode
• starknet_call

Like here: https://github.com/holiman/uint256/blob/master/benchmarks_test.go

Can we create an autorunner for microbenchmarking?

Pending get_state_update availability.

Start moving all StarkNet docs to Juno docs

We need some PR templates to help the PR description process. PRs with blank descriptions are bad for reviewing and documentation. It will also be better for the reviewers to have some comment or description of the work done.

Juno needs a Docker container description so it can be launched as part of various DevOps setups.
For now Juno does not really do anything but as soon as it works as a long running process it should have a Docker image.

Describe the solution you'd like
Just a Dockerfile first and then register it at DockerHub -> contact Nethermind for hosting it under the org.

Add transaction hash calculator as specified in: https://starknet.io/documentation/transaction-structure-and-hash/

FUNCTION SELECTOR
A function selector is an identifier through which the function is callable in transactions or in other contracts. The selector is the sn_keccak hash of the function name, encoded in ASCII.

Plus minimal verification of new transactions.

https://starknet.io/documentation/starknet-state/

STARKNET STATE
The state of StarkNet is a mapping between addresses (251 bit field elements) and contract’s state.

The contract state consists of:

Contract code
Contract storage (a key-value mapping where the key/values are field elements)
With the above definition, we can provide a brief sketch of StarkNet’s transition function. A transaction tx transitions the system from state S to state S’if:

tx is an invoke transaction, and the storage of S’ is the result of executing the target contract code with respect to the previous state S (the arguments, contract address, and the specific entry point are part of the transaction)
tx is a deploy transaction, and S’ contains the new contract’s state at the contract’s address. Additionally, the storage of S is updated according to the execution of the contract’s constructor.

STATE COMMITMENT
The state commitment is a digest which uniquely (up to hash collisions) encodes the state. In StarkNet, the commitment is the root of a binary Merkle-Patricia tree of height 251. Like Ethereum, this is a 2-level structure where the contract address determines the path from the root to the leaf encoding the contract state. The information stored in the leaf is:

h(h(h(contract_hash, storage_root), 0), 0)

Where:

contract_hash is the hash of the contract’s definition discussed here
storage_root is the root of another Merkle-Patricia tree of height 251 that is constructed from the contract’s storage
h is the Pedersen hash function.

Merkle-Patricia tree

As mentioned above, our commitment scheme uses a binary Merkle-Patricia tree with the Pedersen hash function. Each node in the tree is represented by a triplet (length, path, bottom). The actual data is placed in the leaves, and a leaf node with data x is encoded by the triplet (0,0,x). Empty nodes (leaves or internal) are encoded by the zero triplet (0,0,0). A subtree rooted at a node (length, path, bottom) contains a non empty node only at the subtree obtained by following the path specified by path. path is an integer in [0, 2^length-1], and the binary expansion of path indicates how should we proceed along the tree, where the first step is indicated by the most significant bit, and 0,1 are interpreted as left, right correspondingly. Note that the reason that length is specified and cannot be deduced from path is that we’re dealing with field elements of fixed size (251 bits each).

The following rules specify how the tree is constructed from a given set of leaves:

The hash of a node N =(length, path, bottom), denoted by H(N), is:

bottom if length = 0
h(bottom, path) + length otherwise (note that all arithmetic operations are done in our field)
The value of a node whose children are left=(length_l, path_l, bottom_l), right=(length_r, path_r, bottom_r) is:

(0,0,0) if both left and right are empty
(left_l + 1, path_l, left.bottom) if right is empty
(length_r + 1, path_r + 2^length_r, right.bottom) if left is empty
(0, 0, h(H(left), H(right))) otherwise
We now show an example of the construction of a height 3 Merkle-Patricia tree from the leaves [0,0,1,0,0,1,0,0]:

Where r=h(H(2,2,1),H((2,1,1)). Note that in our example there is no skipping from the root (length is zero), so the final commitment to the tree will be H((0,0,r))=r.

Suppose that we want to prove, with respect to the commitment we have just computed, that the value of the leaf whose path is given by 101 is 1. In a standard Merkle tree, the proof would have consisted of data from three nodes (siblings along the path to the root). Here, since the tree is sparse, we only need to send the two children of the root (2,2,1), (2,1,1). This suffices to reproduce the commitment r, and since the height of the tree, 3, is known and fixed, we know that the path 01 of length 2 specified by the right child (2,1,1) leads us to the desired leaf.

CONTRACT ABI
Contract ABI is a representation of a StarkNet contract. It is formatted as a JSON and describes the functions and the structs of the contracts.

You can get it via –

starknet-compile contract.cairo
--output contract_compiled.json
--abi contract_abi.json
or by executing get_code in the StarkNet CLI.

EXAMPLE ABI
[
{
"members": [
{
"name": "x",
"offset": 0,
"type": "felt"
},
{
"name": "y",
"offset": 1,
"type": "felt"
}
],
"name": "Point",
"size": 2,
"type": "struct"
},
{
"inputs": [
{
"name": "a_len",
"type": "felt"
},
{
"name": "a",
"type": "felt*"
}
],
"name": "constructor",
"outputs": [],
"type": "constructor"
},
{
"inputs": [
{
"name": "a_len",
"type": "felt"
},
{
"name": "a",
"type": "felt*"
},
{
"name": "b_len",
"type": "felt"
},
{
"name": "b",
"type": "felt*"
}
],
"name": "input_arrays",
"outputs": [],
"type": "function"
},
{
"inputs": [
{
"name": "array_len",
"type": "felt"
},
{
"name": "array",
"type": "felt*"
}
],
"name": "output_arrays",
"outputs": [
{
"name": "array_len",
"type": "felt"
},
{
"name": "array",
"type": "felt*"
}
],
"type": "function"
},
{
"inputs": [
{
"name": "points",
"type": "(Point, Point)"
}
],
"name": "input_output_struct",
"outputs": [
{
"name": "res",
"type": "Point"
}
],
"type": "function"
}
]

Add sn_keccak support: (find a link to technical doc on it, generally 251 bits of Keccak)

For all the data displayed provide links to Voyager for better UX