stackdump

We recently participated in Base’s on-chain Summer. full code on github: https://github.com/stackdump/on-chain-summer-2024

How it Started

Our intention for this hackathon was to build out an on-chain crafting game.

We didn’t develop it enough to submit for judging, but we did learn a few things about our design.

1. Models have a limit of about 100 objects (places,transitions,arcs) for a single contract deployment.

2. Nodes-as-a-service do not always have a suitable free tier.

3. Our block-synching approach seemed to scale well enough on testnet.

4. The onchain model structure can be improved.

Finding Limits

We discovered that models are limited to about 100 total objects including the types: Places, Transitions, Arcs.

Arcs (0.0279 KiB) are about 2-3x as ‘expensive’ in code as a Place (0.0956 KiB) or Transition (0.0872 KiB).

The Initial design we attempted was about 10 Kib (~48 Arc objects) over the limit for a smart contract max initcode size.

Block Synching

Tested free tier usage from these providers.

• QuickNode – reliable nodes, limited to a single node per project
• BlastApi – crypto native, supports mainnet/testnet for each project.

QuickNode seemed to provide the most credits in a free tier.

BlastAPI seems to be a crypto native approach to hosted nodes, requiring only a wallet to try it out.

In both cases our testnet api seemed to keep up during normal synching.

Block Synching

Our design utilized a postgres database image from supabase: https://github.com/supabase/postgres

Supabase/postgres comes pre-baked with pgnet and pgcron support.

These two features allows for the creation of a self-synching postgres db, where a cron runs pl/sql functions to import block data every 1 min.

We tested using a local image, and the free tier db-as-a-service from supabase.com. In both tests result success was limited by the API we were using, and the DB instance seemed to perform well enough during our week of testing.

Model Improvements

Upon realizing our space limits += 100 objects, we looked to code that could be removed, generally there was some overhead we could lower ~ 2KiB but the contract size growth was mostly related to the complexity of the design.

In the future we intend to investigate some of the multi-contract & library deployment patterns to attempt to create larger model designs.

Conclusion

Though we learned a lot, ultimately we felt that our project wasn’t developed enough to present for judging.

You can see the crafting system design we created below.

You can out the model here: https://pflow.dev/p/zb2rhnuKVVerJd9GA2H4VghgnVUxjUTajKhuaC7XJXjaVUzna/