feat: bounded discrete time #4928

mversic · 2024-08-02T01:11:11Z

Description

put a lower bound on block time (previous block time)
put upper bound on the block time (less than peer current time)

Linked issue

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

I've read CONTRIBUTING.md
I've used the standard signed-off commit format (or will squash just before merging)
All applicable CI checks pass (or I promised to make them pass later)
(optional) I've written unit tests for the code changes
I replied to all comments after code review, marking all implemented changes with thumbs up

Erigara

Can you provide more context for this change.

Also i can't see synchronization part of this PR, am i missing something?

data_model/src/block.rs

core/src/block.rs

Erigara · 2024-08-02T06:05:41Z

data_model/src/block.rs

+
+        fn validate(self) -> Result<BlockHeader, &'static str> {
+            #[cfg(feature = "std")]
+            if std::time::Instant::now().elapsed() < self.creation_time() {


I'm a bit concerned that block validity now depends on when block was received.

can you explain why do you think this is an issue?

i don't think it compromise security, but might harm liveliness if peers clocks drift from each other

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

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

mversic · 2024-08-02T09:59:23Z

Can you provide more context for this change.

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).

Also i can't see synchronization part of this PR, am i missing something?

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

A block was created at 11:25AM and committed
11:25AM becomes the current time (the network is certain that the actual time is no less than that)
Block was committed at 11:35
11:35AM becomes the current time (the network is certain that the actual time is no less than that)

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 contract

A 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

Erigara · 2024-08-02T10:12:15Z

To avoid block rejection can't leader select block time to be as close to the previous block time as possible?
I think it would be considered valid because it's in the range (previous_block_time, min(voting_peer_current_time_1, voting_peer_current_time_n)].

mversic · 2024-08-02T10:35:38Z

To avoid block rejection can't leader select block time to be as close to the previous block time as possible? I think it would be considered valid because it's in the range (previous_block_time, min(voting_peer_current_time_1, voting_peer_current_time_n)].

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.

github-actions · 2024-08-02T10:41:05Z

@BAStos525

core/benches/kura.rs

data_model/src/block.rs

core/src/queue.rs

torii/src/routing.rs

core/src/block.rs

Signed-off-by: Marin Veršić <[email protected]>

mversic requested review from s8sato, SamHSmith, outoftardis, Erigara, 0x009922, DCNick3 and dima74 as code owners August 2, 2024 01:11

mversic force-pushed the validate_block_time branch 2 times, most recently from 2d21f6c to f45e0d4 Compare August 2, 2024 01:31

mversic changed the title ~~feature: synchronized bounded time~~ feature: synchronized bounded discrete time Aug 2, 2024

Erigara reviewed Aug 2, 2024

View reviewed changes

mversic force-pushed the validate_block_time branch from f45e0d4 to 5b31646 Compare August 2, 2024 09:16

github-actions bot added the api-changes Changes in the API for client libraries label Aug 2, 2024

mversic changed the title ~~feature: synchronized bounded discrete time~~ feature: bounded discrete time Aug 2, 2024

mversic force-pushed the validate_block_time branch 5 times, most recently from c48948d to 36dd3f9 Compare August 2, 2024 09:22

mversic changed the title ~~feature: bounded discrete time~~ feat: bounded discrete time Aug 2, 2024

mversic force-pushed the validate_block_time branch from 36dd3f9 to 82d058c Compare August 2, 2024 10:40

github-actions bot added the config-changes Changes in configuration and start up of the Iroha label Aug 2, 2024

mversic force-pushed the validate_block_time branch 4 times, most recently from 1f2d4c0 to 8e70e81 Compare August 2, 2024 13:18

mversic assigned dima74 Aug 19, 2024

mversic force-pushed the validate_block_time branch 2 times, most recently from 10716ff to 30eb7a4 Compare August 21, 2024 11:37

s8sato reviewed Aug 21, 2024

View reviewed changes

core/benches/kura.rs Show resolved Hide resolved

data_model/src/block.rs Show resolved Hide resolved

mversic force-pushed the validate_block_time branch 4 times, most recently from 76ba38a to b44bb57 Compare August 22, 2024 15:35

dima74 reviewed Aug 23, 2024

View reviewed changes

core/src/queue.rs Outdated Show resolved Hide resolved

torii/src/routing.rs Show resolved Hide resolved

s8sato previously approved these changes Aug 23, 2024

View reviewed changes

core/src/block.rs Outdated Show resolved Hide resolved

mversic dismissed s8sato’s stale review via 2e73fe1 August 26, 2024 08:01

mversic force-pushed the validate_block_time branch 6 times, most recently from 078c278 to da4795a Compare August 26, 2024 16:01

mversic mentioned this pull request Aug 26, 2024

Election soundness due to time manipulation #5011

Open

mversic force-pushed the validate_block_time branch from da4795a to 561aa21 Compare August 26, 2024 17:46

s8sato approved these changes Aug 27, 2024

View reviewed changes

dima74 approved these changes Aug 27, 2024

View reviewed changes

feat: bounded discrete time

54f4aed

Signed-off-by: Marin Veršić <[email protected]>

nxsaken force-pushed the validate_block_time branch from 561aa21 to 54f4aed Compare August 27, 2024 08:10

nxsaken disabled auto-merge August 27, 2024 08:10

nxsaken merged commit 3e9cc6f into hyperledger-iroha:main Aug 27, 2024
15 of 18 checks passed

mversic deleted the validate_block_time branch August 27, 2024 08:48

mversic added a commit that referenced this pull request Aug 30, 2024

feat: bounded discrete time (#4928)

f05d088

Signed-off-by: Marin Veršić <[email protected]>

DCNick3 mentioned this pull request Sep 3, 2024

fix: remove executor.wasm from git #5028

Merged

2 tasks

mversic mentioned this pull request Sep 10, 2024

Remove consensus_estimation #5053

Closed

dima74 mentioned this pull request Sep 24, 2024

fix: Fix timestamp of genesis block #5098

Merged

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: bounded discrete time #4928

feat: bounded discrete time #4928

mversic commented Aug 2, 2024 •

edited

Loading

Erigara left a comment

Erigara Aug 2, 2024

mversic Aug 2, 2024

Erigara Aug 2, 2024 •

edited

Loading

mversic Aug 2, 2024

mversic Aug 2, 2024

mversic commented Aug 2, 2024

Erigara commented Aug 2, 2024

mversic commented Aug 2, 2024

github-actions bot commented Aug 2, 2024

feat: bounded discrete time #4928

feat: bounded discrete time #4928

Conversation

mversic commented Aug 2, 2024 • edited Loading

Description

Linked issue

Benefits

Checklist

Erigara left a comment

Choose a reason for hiding this comment

Erigara Aug 2, 2024

Choose a reason for hiding this comment

mversic Aug 2, 2024

Choose a reason for hiding this comment

Erigara Aug 2, 2024 • edited Loading

Choose a reason for hiding this comment

mversic Aug 2, 2024

Choose a reason for hiding this comment

mversic Aug 2, 2024

Choose a reason for hiding this comment

mversic commented Aug 2, 2024

Example

Implementing time based logic in a smart contract

Erigara commented Aug 2, 2024

mversic commented Aug 2, 2024

github-actions bot commented Aug 2, 2024

mversic commented Aug 2, 2024 •

edited

Loading

Erigara Aug 2, 2024 •

edited

Loading