Execution Limits as a Function of Bitcoin Block Times #3241
Replies: 1 comment 1 reply
-
It isn't possible to determine in an absolute sense how long a Bitcoin block took to mine. First, there is know way to predict a priori how long it will take until the next block is discovered. We have a probability function, but that does not tell us anything about particular blocks. So, any such Bitcoin block time determination protocol will require participating nodes to somehow agree on how much wall-clock time was spent waiting for a block once it arrives. The need to get nodes to agree on when a Bitcoin block arrived creates problems, which I'll elaborate on below. Second, such a protocol cannot exist in an open-membership setting and do better than Bitcoin by more than a constant factor, because there can be no global consensus on the true time at which the block arrives, and thus there can be no global consensus on how long it took. There are a couple reasons for this:
What this means is that while it may be possible for Stacks miners watching Bitcoin blocks arrive to execute some sort of voting protocol to decide how long it took for the Bitcoin block to propagate (e.g. to within one RTT), there's no way to authenticate the decisions after the fact. What this in turn means is that whoever are the miners today could vote to decide that a Bitcoin block took 1 day to arrive (or 1 week, or 1 month, etc.), and in doing so, allot themselves arbitrarily many epochs between two Bitcoin blocks and therefore prevent the rest of the network from processing the next Bitcoin block's sortitions (and in doing so, prevent future miners from joining). Therefore, such a block time decision protocol would transform Stacks into a closed-membership system, which we do not want. While it is possible for Stacks nodes to participate in a Bitcoin block time determination protocol built on Nakamoto consensus, such a protocol would de facto re-implement Bitcoin. Nodes would gain no more certainty about the arrival times of Bitcoin blocks from this protocol, because they would in turn be unable to agree on the arrival times of their own messages in this protocol to a degree of precision that is superior to Bitcoin's by any more than a constant factor. I think if you want variable block execution times, you're going to have to come up with a way to do so that doesn't depend on watching the Bitcoin chain. |
Beta Was this translation helpful? Give feedback.
-
Abstract
We propose that optimal throughput on 1) the Stacks chain, and 2) proprietary subnets, depends on the ability for the execution limit budget in a given Bitcoin block round to be a function of the length of time that round (which is not under Stacks' control) takes.
We analyze some data about Bitcoin block times to motivate this statement.
Bitcoin Block Times
Bitcoin is timed so that Blocks are produced on average every 10 minutes. However, the variance and distribution of the actual Bitcoin block times is not shaped like a normal distribution, but like an exponential distribution:
This means that we have:
Empirically, this is what we find in this scrape from Dec 1, 2021:
While a only small minority of blocks take more than 10 minutes (38%), a large majority (75%) of the time spent is in blocks that take longer than 10 minutes. During these "long blocks" latency is bad, and throughput is impaired.
Execution Limits
Execution limits are currently determined based on the smallest blocks. There has to be enough time to 1) process the previous block, and 2) make a new block, between two Bitcoin blocks.
The limit is currently targeted to take around 30 seconds of processing. This means, in the 75% of time that is spent in blocks longer than 10 minutes, we only get 30 seconds of processing done. This includes in intervals that could be 10, 20 or even 30 minutes.
Fixed execution cost limits that are appropriate for short blocks (which are common) will lose time in long blocks.
Variable Execution Cost Limits
Variable execution cost limits would mean that the execution budget for the Stacks chain can grow dynamically during a long block. Somehow, as the Bitcoin block gets longer, the execution cost limit should be increased.
This post asks:
Beta Was this translation helpful? Give feedback.
All reactions