feat: bounded discrete time#4928
Conversation
2d21f6c to
f45e0d4
Compare
Erigara
left a comment
There was a problem hiding this comment.
Can you provide more context for this change.
Also i can't see synchronization part of this PR, am i missing something?
|
|
||
| fn validate(self) -> Result<BlockHeader, &'static str> { | ||
| #[cfg(feature = "std")] | ||
| if std::time::Instant::now().elapsed() < self.creation_time() { |
There was a problem hiding this comment.
I'm a bit concerned that block validity now depends on when block was received.
There was a problem hiding this comment.
can you explain why do you think this is an issue?
There was a problem hiding this comment.
i don't think it compromise security, but might harm liveliness if peers clocks drift from each other
There was a problem hiding this comment.
indeed, drift can happen. This PR assumed nodes synchronize time with an external authority often enough. We can trust that OS will do it (through std::time::SystemTime and ntpd on linux) or we can introduce a separate time tracking via NTP as part of the iroha code running on the node
There was a problem hiding this comment.
This is upper bound. What do you think about having the lower bound? I can only define lower bound if I define both lower and upper. Because if lower bound is defined and block time is set far into the future no new blocks can be produced
f45e0d4 to
5b31646
Compare
c48948d to
36dd3f9
Compare
Sequence of blocks is now guaranteed to have monotonically increasing time. The leader can't just completely fabricate the voted block's creation time because the creation time has to be within some limits (after previous block creation time, but before current validator/observer/proxy node time). If the leader tells a lie within the imposed limits, given enough rotations we should again arrive to the correct value of the time. On average, I'd say that time should remain quite close to the current time (a little bit behind, never in the future).
I removed that word. I meant that it's synchronized in the sense that everybody can agree when the block was created (within an interval). Peers can use blocks creation time to reason about current time. Whatever is the last creation time is the current time across all peers and it increases discretely in intervals. Example
time is discrete in the blockchain because 11:30 is not a valid time, only 11:25, 11:35, etc are valid timestamps Implementing time based logic in a smart contractA smart contract can be given latest block creation time as the current time (a sort of synchronization point) and have logic based on that (understanding the limitations). In the previous example, if the smart contract was written so that it performs a certain action if time is past 11:30AM, it will do it at 11:35AM. But the time of the execution is guaranteed to never be less than 11:30AM |
|
To avoid block rejection can't leader select block time to be as close to the previous block time as possible? |
yes, but then the next leader will correct it, or the one after that. The error doesn't compound or get propagated indefinitely. Network time can drift from the actual current time but not too far. |
36dd3f9 to
82d058c
Compare
1f2d4c0 to
8e70e81
Compare
0b3a15c to
5331ccd
Compare
10716ff to
30eb7a4
Compare
76ba38a to
b44bb57
Compare
078c278 to
da4795a
Compare
da4795a to
561aa21
Compare
Signed-off-by: Marin Veršić <marin.versic101@gmail.com>
561aa21 to
54f4aed
Compare
Description
Linked issue
Closes #4962
Benefits
now have a bounded concept of time that is synchronized across peers.
the time is discrete with increment intervals being the time between 2 blocks
Checklist
CONTRIBUTING.md