[ZIP TBD]: Block time reduction of 75s -> 25s#1215
[ZIP TBD]: Block time reduction of 75s -> 25s#1215ValarDragon wants to merge 5 commits intozcash:mainfrom
Conversation
nuttycom
left a comment
nuttycom
left a comment
There was a problem hiding this comment.
Overall this looks excellent, just a few minor nits/suggestions.
| confirmation to 25 seconds on average. | ||
|
|
||
| - **Greater throughput.** With 3× as many blocks per day and the same | ||
| 2 MB block size limit, we will have proven out higher consensus bandwidth. |
There was a problem hiding this comment.
I think it's a stretch to say we'll have "proven it out"; we'll have raised the theoretical limit, but that's it.
There was a problem hiding this comment.
Fair in that if its never hit, nothing has happened
There was a problem hiding this comment.
Updating to "we will have allocated higher consensus bandwidth capacity"
| This solves three problems. | ||
| - Significantly improves the UX for actors who need 1 or 2 conf's. (Near Intents, small payments) The user-latency goes down 3x. | ||
| - Increases consensus bandwidth, which amplifies the scaling impact of a future shielded pool which does not require shielded sync. | ||
| - Introduces action limits, which short term more than doubles the Orchard TPS (2.9 → 6.1 TPS), while lowering the worst-case sandblast bandwidth on shielded sync by 42% (270.5 → 156.83 MB/day). |
There was a problem hiding this comment.
| - Introduces action limits, which short term more than doubles the Orchard TPS (2.9 → 6.1 TPS), while lowering the worst-case sandblast bandwidth on shielded sync by 42% (270.5 → 156.83 MB/day). | |
| - Introduces action limits, which short term more than doubles the Orchard TPS (2.9 → 6.1 TPS), while reducing the bandwidth required for shielded wallet sync in the case of maximally-full blocks by 42% (270.5 → 156.83 MB/day). |
Should we also introduce transparent action limits? That seems like a natural step to take now.
There was a problem hiding this comment.
Do we need a transparent limit? I'd suggest we do that after a pool with no shielded sync for clients is deployed
| That analysis suggests that this would improve finality times by a factor of at | ||
| least 2.9, if you assume the attacker has a fixed percentage of network |
There was a problem hiding this comment.
I find stating this as "improve finality time by " to be a confusing way to state this; given constant hashpower and the potential for rollbacks, how is "finality" defined?
There was a problem hiding this comment.
Thank you! Your right this was confusing. I rewrote this section, hopefully it reads clearer now right?
Co-authored-by: Kris Nuttycombe <kris@nutty.land>
str4d
added
the
S-waiting-on-review
| analysis in various attack models. As this proposal meets the constraint of | ||
| keeping stale rates low, this should under the "X% of hashpower is byzantine" | ||
| threat model improve user confirmation times by a factor slightly under 3x. | ||
| Under the posts "Economic" threat model, where the user requires the block |
There was a problem hiding this comment.
Ah, I should re-link the citation there, your right!
| However, we do expect many classes of users to be able to wall-clock lower | ||
| theirs under consistent threat modelling of what they choose today. |
There was a problem hiding this comment.
This sentence is a bit Byzantine itself.
Co-authored-by: Kris Nuttycombe <kris@nutty.land>
4 participants
This PR introduces a candidate block time reduction from 75s to 25s.
To protect against shielded sync increases, it furthermore includes "action limits" per pool type. Changing:
I made this simulator to show the shielded sync load: http://164.92.225.227:5174/ (URL will be updated soon), which also shows how load can update with related changes. These action limits also make the deployment of memo-bundles easier to reason about from a burden overhead on shielded sync.
I will keep iterating on precise timing estimates for full node processing times with @evan-forbes soon.