Comments (5)
A runtime benchmark table for opcodes + pricing table is in the works.
from snarkvm.
EDIT: still syncing with Mike on this.
Hi @pranav and @howard, after syncing with Mike today, we believe we need the following adjustments, let us know if you agree with the direction:
1. Set BLOCK_SPEND_LIMIT
to a number of credits equal to the price of a finalize block of 7.5 seconds.
- Suggestion: Mike will still continue analysis on this, but based on our current model it is likely above 100 credits.
2. Limit number of bytes hashed in finalize blocks as defense in depth.
- Suggestion: 4 million bytes, as BHP hashing 4 million bytes takes 2 seconds in Mike's benchmarks.
3. Set a TRANSACTION_SPEND_LIMIT
, for UX reasons, so a single transaction can't eat up all the finalize space.
- Suggestion: BLOCK_SPEND_LIMIT
/ 100.
from snarkvm.
Basically as priced currently in the SnarkVM code. Opcodes are currently priced such that 1 second of runtime costs 100 credits. This was future proofing to ensure that in the future, people can reasonably afford to use hash functions. However governance will be able to set future prices to ensure network usability, so at the outset hash function prices can be higher as they're most abuse-able opcode.
Raising the per byte
cost reasonably prices out using high byte inputs like nested arrays
but it still leaves open the ability for people to use spend much less money to extended the block time using a LOT of hashes on smaller byte inputs like field
elements. Limiting the # of hashes per execution doesn't solve this as people could send many executions at the maximum limit and achieve the same result.
What would be sensible is in my opinion
-
Increase the base price of all the hash opcodes 10x (at least) at network outset so users trying to flood many hash executions reach the
BLOCK_SPEND_LIMIT
much faster before they can slow down block times. Also it would discourage people attempting the attack (as well as just excessive hash usage from poor finalize scope design) because of how expensive it is. I'm convinced this is a measure that should be taken. -
A
TRANSACTION_SPEND_LIMIT
orMAX_BYTES_HASHED
per executions, would implicitly limit single programs from using a lot of hashes, which would be helpful, but it wouldn't limit the flood case. -
Potentially putting a
hash
limit per block or limit the# of total bytes
hashed per block. This is the weirder option, but it would definitively stop validators from trying to process an amount of hash function usage that slows the network.
from snarkvm.
On #2, does the BLOCK_SPEND_LIMIT
address the flood case?
The total spent in a block is the sum of the cost of the accepted and rejected executions.
If an execution's cost results in the running total exceeded BLOCK_SPEND_LIMIT
then it's aborted.
from snarkvm.
@d0cd the conclusion I've come to is that a sufficiently low BLOCK_SPEND_LIMIT
somewhere around 750
as you've suggeested and an increase of them current hash opcode prices 20x
should be sufficient to prevent DoS attacks via Hash opcodes (and also has the benefit of being the simplest option).
I'd recommend we go with this route.
from snarkvm.
Related Issues (20)
- [Feature] Better UI for Users HOT 1
- [Bug]rustc version
- [Bug]rusc version
- Optimizations to struct deserialization HOT 1
- [Feature] HOT 1
- [Bug] Aleo variable index array access HOT 1
- [Optimization] Inefficient fetching of `credits.aleo` PKs HOT 2
- Multiple crates missing `repository` field HOT 1
- [Bug] Truncated `ARCHOR_HEIGHT` leads to less `coinbase_reward` than expected HOT 5
- [Bug] No constant `BLOCK_TIME` with Bullshark HOT 6
- bug: incorrect timestamp in explorer HOT 1
- No need to create a credits with microcredits =0 HOT 2
- [Bug]Malicious validators can prevent legitimate transactions from being executed. HOT 6
- [Bug] Credits.aleo HOT 6
- When you are going build with rust on Linux HOT 5
- [Bug] The delegator may fail to execute unbond_public
- Flaky Tests on CI HOT 3
- dependencies for a Rust project HOT 1
- [Bug] Incorrect `next_coinbase_target` update HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from snarkvm.