How does NOW work?
Say a contract has a condition based on NOW being after a time. Is NOW UTC, and is this validated by each node before being added to the chain? Let's say you want ensure a function is called during a 1 hour window, will this be possible to enforce?
For example:
current stack state: NOW - 15 minutes :: NOW + 45 minutes //pseudocode
code: NOW; SUB; GT; SWAP;
NOW; SWAP; SUB;
AND;
IF { send transaction... } { FAIL; };
This should check that it's greater than NOW - 15 minutes and less than NOW + 45 minutes, which are both true so it can execute the transaction.
It might also be important to understand how the network gets consensus on a block time across the network?
michelson
asked 19 hours ago
RobRob
2835
add a comment |
Say a contract has a condition based on NOW being after a time. Is NOW UTC, and is this validated by each node before being added to the chain? Let's say you want ensure a function is called during a 1 hour window, will this be possible to enforce?
For example:
current stack state: NOW - 15 minutes :: NOW + 45 minutes //pseudocode
code: NOW; SUB; GT; SWAP;
NOW; SWAP; SUB;
AND;
IF { send transaction... } { FAIL; };
This should check that it's greater than NOW - 15 minutes and less than NOW + 45 minutes, which are both true so it can execute the transaction.
It might also be important to understand how the network gets consensus on a block time across the network?
michelson
asked 19 hours ago
RobRob
2835
add a comment |
Say a contract has a condition based on NOW being after a time. Is NOW UTC, and is this validated by each node before being added to the chain? Let's say you want ensure a function is called during a 1 hour window, will this be possible to enforce?
For example:
current stack state: NOW - 15 minutes :: NOW + 45 minutes //pseudocode
code: NOW; SUB; GT; SWAP;
NOW; SWAP; SUB;
AND;
IF { send transaction... } { FAIL; };
This should check that it's greater than NOW - 15 minutes and less than NOW + 45 minutes, which are both true so it can execute the transaction.
It might also be important to understand how the network gets consensus on a block time across the network?
michelson
asked 19 hours ago
RobRob
2835
Say a contract has a condition based on NOW being after a time. Is NOW UTC, and is this validated by each node before being added to the chain? Let's say you want ensure a function is called during a 1 hour window, will this be possible to enforce?
For example:
current stack state: NOW - 15 minutes :: NOW + 45 minutes //pseudocode
code: NOW; SUB; GT; SWAP;
NOW; SWAP; SUB;
AND;
IF { send transaction... } { FAIL; };
This should check that it's greater than NOW - 15 minutes and less than NOW + 45 minutes, which are both true so it can execute the transaction.
It might also be important to understand how the network gets consensus on a block time across the network?
michelson
michelson
asked 19 hours ago
RobRob
2835
asked 19 hours ago
RobRob
2835
asked 19 hours ago
RobRob
2835
asked 19 hours ago
RobRob
2835
asked 19 hours ago
RobRob
2835
2835
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
There is an assumption that all Tezos nodes are synchronized, otherwise the consensus with 1-minute slots would not work. Of course, some delay is ok, but more than a few seconds might prevent a baker from baking.
NOW is the time at which the block, containing the transaction, should be baked. So, the baker knows the last block time, he knows his slot, so he can compute the time at which he should bake the block. It then uses that time to execute the transactions.
answered 13 hours ago
lefessanlefessan
2,557522
add a comment |
Nodes time being synchronized is only part of the picture: bakers can always be offline for their own reasons, the network can be stalled, many other transactions could be competing to get selected by bakers, etc. so people need to be very cautious and give plenty of time for an event to occur.
I would say that a few minutes or even hours is not enough today.
Is one day enough ? I would tend to think so but I'm not even certain.
answered 11 hours ago
FFFFFF
621212
If I'm experimenting with building something that can hit milestones during smaller ranges. Kind of curious how close those milestones can be.
– Rob
9 hours ago
2
Understood but let's all remember Fomo3d medium.com/coinmonks/… on Ethereum before requiring milestones too fast.
– FFF
9 hours ago
add a comment |
The baker chooses the value of NOW. I am aware of these two constraints:
The protocol enforces that the timestamp is at least the minimal timestamp at which the baker was supposed to bake (some delay after the previous block's timestamp): baking.ml.
The shell will also ignore a block whose timestamp is too far in the future (more than 15s) relative to the system clock: distributed_db.ml.
answered 7 hours ago
TomTom
87327
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "698"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftezos.stackexchange.com%2fquestions%2f735%2fhow-does-now-work%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
There is an assumption that all Tezos nodes are synchronized, otherwise the consensus with 1-minute slots would not work. Of course, some delay is ok, but more than a few seconds might prevent a baker from baking.
NOW is the time at which the block, containing the transaction, should be baked. So, the baker knows the last block time, he knows his slot, so he can compute the time at which he should bake the block. It then uses that time to execute the transactions.
answered 13 hours ago
lefessanlefessan
2,557522
add a comment |
There is an assumption that all Tezos nodes are synchronized, otherwise the consensus with 1-minute slots would not work. Of course, some delay is ok, but more than a few seconds might prevent a baker from baking.
NOW is the time at which the block, containing the transaction, should be baked. So, the baker knows the last block time, he knows his slot, so he can compute the time at which he should bake the block. It then uses that time to execute the transactions.
answered 13 hours ago
lefessanlefessan
2,557522
add a comment |
There is an assumption that all Tezos nodes are synchronized, otherwise the consensus with 1-minute slots would not work. Of course, some delay is ok, but more than a few seconds might prevent a baker from baking.
NOW is the time at which the block, containing the transaction, should be baked. So, the baker knows the last block time, he knows his slot, so he can compute the time at which he should bake the block. It then uses that time to execute the transactions.
answered 13 hours ago
lefessanlefessan
2,557522
There is an assumption that all Tezos nodes are synchronized, otherwise the consensus with 1-minute slots would not work. Of course, some delay is ok, but more than a few seconds might prevent a baker from baking.
NOW is the time at which the block, containing the transaction, should be baked. So, the baker knows the last block time, he knows his slot, so he can compute the time at which he should bake the block. It then uses that time to execute the transactions.
answered 13 hours ago
lefessanlefessan
2,557522
answered 13 hours ago
lefessanlefessan
2,557522
answered 13 hours ago
lefessanlefessan
2,557522
answered 13 hours ago
lefessanlefessan
2,557522
2,557522
add a comment |
add a comment |
Nodes time being synchronized is only part of the picture: bakers can always be offline for their own reasons, the network can be stalled, many other transactions could be competing to get selected by bakers, etc. so people need to be very cautious and give plenty of time for an event to occur.
I would say that a few minutes or even hours is not enough today.
Is one day enough ? I would tend to think so but I'm not even certain.
answered 11 hours ago
FFFFFF
621212
If I'm experimenting with building something that can hit milestones during smaller ranges. Kind of curious how close those milestones can be.
– Rob
9 hours ago
2
Understood but let's all remember Fomo3d medium.com/coinmonks/… on Ethereum before requiring milestones too fast.
– FFF
9 hours ago
add a comment |
Nodes time being synchronized is only part of the picture: bakers can always be offline for their own reasons, the network can be stalled, many other transactions could be competing to get selected by bakers, etc. so people need to be very cautious and give plenty of time for an event to occur.
I would say that a few minutes or even hours is not enough today.
Is one day enough ? I would tend to think so but I'm not even certain.
answered 11 hours ago
FFFFFF
621212
If I'm experimenting with building something that can hit milestones during smaller ranges. Kind of curious how close those milestones can be.
– Rob
9 hours ago
2
Understood but let's all remember Fomo3d medium.com/coinmonks/… on Ethereum before requiring milestones too fast.
– FFF
9 hours ago
add a comment |
Nodes time being synchronized is only part of the picture: bakers can always be offline for their own reasons, the network can be stalled, many other transactions could be competing to get selected by bakers, etc. so people need to be very cautious and give plenty of time for an event to occur.
I would say that a few minutes or even hours is not enough today.
Is one day enough ? I would tend to think so but I'm not even certain.
answered 11 hours ago
FFFFFF
621212
Nodes time being synchronized is only part of the picture: bakers can always be offline for their own reasons, the network can be stalled, many other transactions could be competing to get selected by bakers, etc. so people need to be very cautious and give plenty of time for an event to occur.
I would say that a few minutes or even hours is not enough today.
Is one day enough ? I would tend to think so but I'm not even certain.
answered 11 hours ago
FFFFFF
621212
answered 11 hours ago
FFFFFF
621212
answered 11 hours ago
FFFFFF
621212
answered 11 hours ago
FFFFFF
621212
621212
If I'm experimenting with building something that can hit milestones during smaller ranges. Kind of curious how close those milestones can be.
– Rob
9 hours ago
2
Understood but let's all remember Fomo3d medium.com/coinmonks/… on Ethereum before requiring milestones too fast.
– FFF
9 hours ago
add a comment |
If I'm experimenting with building something that can hit milestones during smaller ranges. Kind of curious how close those milestones can be.
– Rob
9 hours ago
2
Understood but let's all remember Fomo3d medium.com/coinmonks/… on Ethereum before requiring milestones too fast.
– FFF
9 hours ago
If I'm experimenting with building something that can hit milestones during smaller ranges. Kind of curious how close those milestones can be.
– Rob
9 hours ago
If I'm experimenting with building something that can hit milestones during smaller ranges. Kind of curious how close those milestones can be.
– Rob
9 hours ago
2
2
Understood but let's all remember Fomo3d medium.com/coinmonks/… on Ethereum before requiring milestones too fast.
– FFF
9 hours ago
Understood but let's all remember Fomo3d medium.com/coinmonks/… on Ethereum before requiring milestones too fast.
– FFF
9 hours ago
add a comment |
The baker chooses the value of NOW. I am aware of these two constraints:
The protocol enforces that the timestamp is at least the minimal timestamp at which the baker was supposed to bake (some delay after the previous block's timestamp): baking.ml.
The shell will also ignore a block whose timestamp is too far in the future (more than 15s) relative to the system clock: distributed_db.ml.
answered 7 hours ago
TomTom
87327
add a comment |
The baker chooses the value of NOW. I am aware of these two constraints:
The protocol enforces that the timestamp is at least the minimal timestamp at which the baker was supposed to bake (some delay after the previous block's timestamp): baking.ml.
The shell will also ignore a block whose timestamp is too far in the future (more than 15s) relative to the system clock: distributed_db.ml.
answered 7 hours ago
TomTom
87327
add a comment |
The baker chooses the value of NOW. I am aware of these two constraints:
The protocol enforces that the timestamp is at least the minimal timestamp at which the baker was supposed to bake (some delay after the previous block's timestamp): baking.ml.
The shell will also ignore a block whose timestamp is too far in the future (more than 15s) relative to the system clock: distributed_db.ml.
answered 7 hours ago
TomTom
87327
The baker chooses the value of NOW. I am aware of these two constraints:
The protocol enforces that the timestamp is at least the minimal timestamp at which the baker was supposed to bake (some delay after the previous block's timestamp): baking.ml.
The shell will also ignore a block whose timestamp is too far in the future (more than 15s) relative to the system clock: distributed_db.ml.
answered 7 hours ago
TomTom
87327
answered 7 hours ago
TomTom
87327
answered 7 hours ago
TomTom
87327
answered 7 hours ago
TomTom
87327
87327
add a comment |
add a comment |
Thanks for contributing an answer to Tezos Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftezos.stackexchange.com%2fquestions%2f735%2fhow-does-now-work%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
