Eventlog contract calls time.Now()

[jeffallen]

Contracts must be time invariant, but eventlog is not.

See also #1331.

[ineiti]

You can use GetCurrentBlockTimestamp from here: https://github.com/dedis/cothority/blob/38ff4b738211855c76c70f37c6d2db70655633f6/byzcoin/statetrie.go#L69

An example is here:

https://github.com/dedis/cothority/blob/6e091325f840c3683f90c4c94cf116449112f9e5/bevm/contract.go#L312

[pierluca]

@ineiti @jeffallen

My understanding is that event logs could be accepted only between GetCurrentBlockTimestamp() (- a few seconds) as lower bound and GetCurrentBlockTimestamp() + config.BlockInterval as upper bound.

However, I have doubts concerning how BlockInterval is defined. My understanding is that it's used as a timeout for the generation of a single block.

However, on the following line, the magic number "4" is used as a multiplicative factor to create a window larger than BlockInterval to validate a block. What does that 4 represent? Is BlockInterval a hard timeout on the creation of a new block or is 4*BlockInterval ? https://github.com/dedis/cothority/blob/63a2ff92c6516a5bb1469170f69dd8a3c21ce883/byzcoin/service.go#L2171-L2178

The BlockInterval parameter itself seems to be undocumented: https://github.com/dedis/cothority/blob/63a2ff92c6516a5bb1469170f69dd8a3c21ce883/byzcoin/proto.go#L167-L170 I'm happy to document it once this is clarified.

[ineiti]

Yes, documenting would be good ;)

Historically, blockinterval was the time the leader spent between a new block has been generated, and the time it asked the other nodes if there are any new transactions pending. Which made two blocks appear about twice the blockInterval in case there was a continuous stream of transactions.

Lately I changed the protocol to https://github.com/dedis/cothority/pull/2321, so that the nodes directly forward all transactions to the leader, who queues them up and creates blocks as long as there are transactions in the queue.

So now theblockInterval is more used as a maximum propagation time.

The magic 4 is an experimental value that allows for blocks to be created within 4 * blockInterval. This allows for some clock-skew between the nodes, as well as network propagation and contract-execution-time.

[pierluca]

@ineiti Am I then correct in understanding that there's no upper bound in how long it may take for a new block to be added to the blockchain, provided the participants in the blockchain do not desire to carry out some operation on it? Rephrasing: there's no heartbeat on the ledger itself, merely (I imagine) at the network level?

[ineiti]

The basic assumption is that at least 2f+1 out of 3f+1 participants follow the protocol. So as long as only f participants or less try to delay or withhold their signature, all should be fine.

If the leader is byzantine (faulty or malicious), there will be a leader-rotation until a leader is found who successfully gets a block signed.

So there is no heartbeat. If a node tries to get a transaction signed, and there is a timeout, he will propose to re-elect the leader.

[pierluca]

That is clear.

I rather meant that, in my understanding, in the absence of activity (e.g. an instruction being sent by a client), no blocks are added. That is, there's no guarantee that no more than X [units of time] have passed since a block was last added to the ledger.

Basically, if a cothority was active, but has been idle for the last month and everything is stable (all nodes continuously online, no failures, etc.), the latest block on the ledger will be from a month ago. Correct?

It seems reasonable, I'm just trying to proceed with few assumptions as I am not yet familiar with the codebase.

[ineiti]

Yes, there are no 'filler' blocks that are sent with an empty list of transactions. Although the statistics at https://stats.c4dt.org produce about 10 blocks an hour.

[ineiti]

See also #2378

[ineiti]

Bump @pierluca ?