Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug][Canary] Block times affected by transaction volume and type #3

Open
krwang opened this issue Apr 10, 2024 · 1 comment
Open
Labels
bug Something isn't working

Comments

@krwang
Copy link

krwang commented Apr 10, 2024

We have observed variation in the block times, most notably when Demox executed a persistent deployment cannon on canary net.

Over the course of the 12 hour test, canary sustained 1 deployment per second, for a program with 280k constraints. During that time, block times consistently remained above 60 seconds. Immediately after the cannon was turned off, block times returned to the normal 4-5 seconds.

image

By adjusting the number of deployments per second, along with the constraint size of the program, we can reliably control the block times of canary.

Anecdotally, we have also observed slight variation in block times due to public transactions being fired at canary, varying from 1 TPS to 10. The block times were not drastically different and were often times faster than the usual 4-5 seconds. This is also visible in the above graph, illustrated by the changing slope of the line prior to the deployment slowdown.

Steps to Reproduce

Execute script to fire X deployments per second at a client node in canarynet.

Expected Behavior

  • Block times remain consistent
  • Transactions are dropped or fewer transactions are taken from the mempool

Your Environment

The cannon was executed from EC2 linux machines and pointed at Demox's client node, running a fork of snarkOS with commits up to 6aba25d.

@krwang krwang added the bug Something isn't working label Apr 10, 2024
@vicsn
Copy link

vicsn commented Apr 16, 2024

Thank you for notifying. This is known behaviour. Noting that:

  • Doing this for 12 hours would cost ~12M Aleo Credits, which is 1/3rd of the initial months total circulating supply.
  • This PR will only make this spam possible if it comes from different addresses

However, I recall @evanmarshall wanted to see if he could pull off the attack for way less credits, which is a valid endeavour.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants