2024-02-26
Introducing Proposer-Based Timestamps (PBTS) in CometBFT
CometBFT is set to introduce a significant upgrade in the upcoming v1 release that promises to enhance the performance of blockchain operations through Proposer-Based Timestamps (PBTS).
Historically, CometBFT, like many other BFT consensus engines, has been using BFT time to timestamp blocks. In contrast to the BFT Time approach, PBTS brings many benefits for application developers building on CometBFT.
Adopting Proposer-Based Timestamps (PBTS) in CometBFT will improve efficiency by ensuring an improved correlation between block timestamps and real-world time (UTC). PBTS will benefit light clients by providing more reliable block verification. It will also enable potential optimizations such as validator signature aggregation. PBTS will simplify the timestamping process, and enhance the reliability of time-sensitive applications such as Perpetuals and DEXes.
Table of Contents
Limitations of BFT Time
CometBFT currently employs a method of timestamping blocks known as BFT Time. This ensures timestamps in each block are monotonically increasing and progresses within the bounds of the values of clocks of non-byzantine nodes. Upon creation of each new block, the proposer determines the block's timestamp by calculating the weighted median of the timestamps from all received pre-commit messages for the previous block. The weight corresponds to the validator's voting power or stake in the network at that height. This is a good solution allowing the blockchain to be used as a source of time.
This system's approach to time generation is straightforward in that each validator contributes a timestamp in their pre-commit message. The timestamp provided by a validator reflects either the current Unix time known to the validator or a value one millisecond higher than the time of the previous block, whichever of the two is larger.
However, the BFT time approach has some limitations. First, there is no requirement for validators to check how far away each received precommit’s timestamp is with respect to their own current Unix time. Thus, there is no strong relation between block timestamps and the actual time at which they were produced.
Second, and more importantly, notice that timestamps are a field in pre-commit messages. This means pre-commit messages from different validators have different payloads (the timestamp), and consequently CometBFT cannot support signature aggregation (BLS) of these votes. In turn, this hinders a potential avenue for improving the scalability of CometBFT with respect to validator set size.
By using PBTS the above limitations are addressed. Below we describe PBTS and mention other key advantages of this approach.
What is Proposer-Based Timestamps (PBTS)?
Proposer-Based Timestamps (PBTS) is a new algorithm for calculating block timestamps amongst validators for CometBFT based blockchain networks. Briefly, PBTS gives the block proposer – the node that creates a new candidate block – the responsibility of assigning a timestamp to the new block.
Why does PBTS matter?
The introduction of PBTS in CometBFT aims to simplify the timestamping process and more closely correlate the block times and the times where the blocks were created. With PBTS, we replace a "timeless" validation to a "timely" validation.
Key benefits of adopting PBTS:
Improved Reliability for Time-sensitive Applications: PBTS Provides a more predictable and reliable timestamping mechanism, which is crucial for applications that rely on precise timing for transactions, such as un-bonding staked assets or timeout of IBC packets. In BFT Time, the potential for variance, and the weak enforcement of the skew between block times and actual time, in the selected timestamp may affect applications requiring high time accuracy. This is an important aspect for applications such as perpetuals trading or DEXes (such as Osmosis or dYdX).
Better Alignment with Light Clients' Needs: Light Clients rely on correspondence between their known time and the block time for block verification. PBTS ensures that timestamps are more closely aligned with real-world time, improving the reliability of block verification by light clients, which rely on accurate and predictable timestamps. Due to the limitations inherent in BFT Time, there can be significant discrepancies between a light client's Unix time and the block timestamp, affecting the reliability of block verification.
Potential for Signature Aggregation: Using PBTS in CometBFT unlocks future optimizations such as aggregation of validator signatures and opens up the possibilities for potential new use cases such as BLS signatures and MPC computations.
Simplified Timestamp Agreement and Increased Efficiency: In PBTS, the block proposer unilaterally decides the timestamp, so there's no need for complex calculations or agreements among validators to calculate the timestamp. Further, this mitigates the potential introduction of skews when collecting and calculating the median of all validator timestamps.
How Does PBTS Work?
With PBTS, the timestamp of a block is assigned by its proposer, according to its local clock. In other words, the proposer of a block also proposes a timestamp for the block. Validators can accept or reject a proposed block. A block is only accepted if its timestamp is acceptable.
A proposed timestamp is acceptable if it is received within a certain time window, determined by synchrony-related parameters.
Synchronous Parameters
For validating timestamps, PBTS augments the system model considered by the consensus algorithm with synchrony assumptions:
Synchronized clocks: simultaneous clock reads at any two correct validators differ by at most PRECISION;
Bounded message delays: the end-to-end delay for delivering a Proposal message, broadcast by a proposer, to all correct validators is bounded by MSGDELAY.
PRECISION and MSGDELAY are consensus parameters, shared by all validators, that define whether the timestamp of a block is acceptable, according to the introduced timely predicate.
Timestamp Validation
The timely predicate is defined as follows. Let proposalReceiveTime be the time, read from its local clock, at which a validator receives a Proposal message for a block with timestamp ts = block.time.
The proposed timestamp ts is considered timely if both:
ts <= proposalReceiveTime + PRECISION
ts >= proposalReceiveTime - MSGDELAY - PRECISION
The following diagram graphically represents the conditions for accepting a proposed timestamp:
Looking Ahead
The team has been diligently working on adding PBTS functionality to CometBFT. Although there are some minor tasks that still need to be completed, this feature will be included in the upcoming v1 release.
We are thrilled about the potential use cases and opportunities this feature will bring to the ecosystem.