Starknet Devnet

🙏 Help and Support Site Feedback
,
1

This is a topic for issues, requests and news on Starknet Devnet.

100 Likes
2

Starknet Devnet repo is here GitHub - Shard-Labs/starknet-devnet: A local testnet for Starknet

72 Likes
3

New version of starknet-devnet (v0.1.8) has been released:

  • Prevent Internal Server Error if deploying a contract compiled with an old compiler version.
  • Make the result of starknet tx_status more similar to that of Alpha testnet.
  • Support starknet get_storage_at.
  • Support starknet get_code.
  • Add lists of supported and unsupported Starknet CLI commands to Readme.
53 Likes
4

The version released this morning was not compatible with Python versions 3.7 and 3.8. Thanks to Jakub Ptak for fixing this and helping release v0.1.9:

50 Likes
5

Forking was proposal in last week’s community call and in a GitHub issue yesterday: Mainnet forking · Issue #18 · Shard-Labs/starknet-devnet · GitHub
Don’t hesitate to share your thoughts!

35 Likes
6

An interesting page to help designing this

Devnet already allows executing smart contracts against local state, correct?
The missing piece seems to be being able to pull part of the global starknet state from the sequencer?

38 Likes
7

Thanks for the link! Yes, I think you’re right.

33 Likes
8

Hey,
With these APIs you can query the code and the state of a contract at a specific block. Is that enough?

get_storage_at

and

get_code

https://starknet.io/starknet-cli/

31 Likes
9

I’m not sure how all the cases should be covered; in fact I’m not even sure which cases there are. There could be mainnet contracts, and newly deployed contracts only available on the fork. So if the devnet gets an invoke/call request, it should first check its own state, then query the mainnet.

But I’m not sure about the L2-L2 interaction case: What if one contract is on mainnet and the other is on devnet; how would they interact?

Also, if there is an invoke request that changes the state of a previously deployed contract, how should the new state be preserved on the fork only? Could that previously deployed contract be copied to the fork when such need arises?

30 Likes
10

Also, the APIs you mentioned (get_storage_at, get_code), they seem useful for our use case, but I’m not sure if it’s directly them that should be called. Because these are the subcommands (tasks) of the starknet CLI tool. The devnet would probably not call the CLI tool, but perform HTTP requests in case it doesn’t encounter the requested data in its own state. The devnet already mimicks the testnet HTTP endpoints, so in those endpoints, it could pass on the same request, but to a different host (mainnet, testnet, whichever).

28 Likes
11

I think an easy way to do it is to assume a state is unknown unless it was already recovered from the forked state (by either get_code or get_storage). I don’t think there should be “mainnet” state and “devnet” state, but you just assume all the state is a snapshot of a specific block, and you discover it upon need.

But I’m not sure about the L2-L2 interaction case: What if one contract is on mainnet and the other is on devnet; how would they interact?

They should just interact regularly, but you should fill in the state for unknown slots by making the calls mentioned above.

The only problem I can see with this approach is that the interaction with StarkNet is pretty slow at the moment, so it might make the interaction with the snapshot really slow.
Hopefully it will be faster, and once API service like Infura/Figment will provide support for Starknet (yes it will happen sooner rather than later), they can also be used for that!

30 Likes
12

My understanding is that when the forked node receives a transaction that changes state, it applies the transaction to the mainnet state and store it in the fork. The challenge is then knowing what state is in the devnet fork and what is on mainnet. Ganache does that in their implementation of the state trie.

27 Likes
13

Hello!
Check this out What's the API endpoint for Starknet? - #3 by fracek
We have not documented the http API yet, but somebody infered it:
What's the API endpoint for Starknet? - #3 by fracek

25 Likes
14

Well, the devnet already provides basically the same HTTP API as testnet. Adding a --fork option to the devnet would just enable altering how the HTTP endpoints behave (sometimes communicate with testnet/mainnet). Hopefully next week I’ll be able to use the ideas mentioned here and see where that takes us.

27 Likes
15

New version of starknet-devnet (v0.1.10) has been released (GitHub):

  • Adapt to work with cairo-lang v0.6.2.
  • Replicate the new transaction statuses (transactions are now ACCEPTED_ON_L2).

Features to come (most likely not in the next version): supporting starknet get_block, supporting starknet get_transaction_receipt, L1-L2 interaction, testnet/mainnet forking.

25 Likes
16

So, the command starknet get_code:

  • receives a contract_address
  • returns an object with two parts:
    • abi
    • bytecode

I don’t understand two things

  1. How can abi and bytecode be used to reconstruct the state? Can a StarknetContract or its StarknetState be reconstructed in the testing framework using those artifacts? Or, hypothetically speaking, could it be possible to redeploy a contract from those two artifacts?
  2. get_code also receives a block identifier (hash or number) - how does that come into play? Does the code change over time?

I’ve only been able to make little progress on this topic, mostly because of dealing with other project-related issues; I apologize for not having done more.

26 Likes
17

New version of starknet-devnet (v0.1.11) has been released:

  • Add block support.

  • Add partial receipt support (missing for deploy transactions; coming with next version of cairo-lang).

  • Use official hash calculation function (instead of numbering tx hashes in order; block hash calculation coming with next version of cairo-lang).

  • Refactor to prepare for the incoming forking support.

27 Likes
18

New version of starknet-devnet (v0.1.12) has been released:

  • Prevent Internal Server Error (500) from arising if deployment fails.
  • Ignore duplicate deployments (e.g. in case of same salt).
23 Likes
19

New version of starkent-devnet (v0.1.13) has been released:

  • Use cairo-lang 0.7.0 for internal execution (will allow deploying contracts compiled with 0.7.0).
  • Support arrays of structs in function inputs.
  • Include execution info in deploy transaction receipt.
  • Calculate block hash correctly.
  • Improve logging if case of version mismatch (mismatch between version used for compilation and version used by devnet).
23 Likes
20

New version of starknet-devnet (v0.1.14) has been released:

  • Include events in transaction receipts.
  • Allow transactions/calls with no signature (so far empty signature was accepted, but some tools provide no signature at all, e.g. starknet.js).
  • In transaction and receipt objects, rename transaction_failure_reason to tx_failure_reason:
    • This enables the --error_message option of starknet tx_status.
25 Likes