feat: Include fractions in epoch number representations #1585
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
yangby-cryptape
requested changes
Sep 12, 2019
yangby-cryptape
requested changes
Sep 12, 2019
yangby-cryptape
approved these changes
Sep 12, 2019
jjyr
reviewed
Sep 17, 2019
u2
reviewed
Sep 18, 2019
| ); | ||
|
|
||
| let median_time_context = MockMedianTime::new(vec![0; 11]); | ||
| assert!(verify_since(&rtx, &median_time_context, 5, 1).is_ok(),); |
There was a problem hiding this comment.
Is it a valid or invalid since? For the test name test_invalid_zero_length_since, it's an invalid since, but verify_since is is_ok().
56 bits?
|
quake
approved these changes
Sep 19, 2019
CKB - Pull Requests
automation
moved this from 👀 Awaiting review
to ✅ Reviewer approved
Sep 19, 2019
This change introduce fractions in 2 places where epoch numbers might be used: * The epoch field in the header * Cell input's since part when using epoch values Specifically, the new epoch number format works as follows: * Only the lower 56 bits of the full 64-bit value are used * The upper 40 bits are used to represent the current epoch number * The lower 16 bits represent the already elapsed fractions of current epoch(not including current block) Assuming we are at block number 11555, epoch 50, and epoch 50 starts from block 11000, has a length of 1000. The epoch number for this particular block will then be 3313172, which is calculated in the following way: ``` (50 << 16) | (((2 ** 16) * (11555 - 11000) / 1000) & ((2 ** 16) - 1)) ``` Note the formula uses normal integer division which rounded to the floor. This way, we can alleviate the trouble that CKB uses variable epoch length. The actual contract or dapps can just read this epoch number with fractions and perform numerical operations as normal.
This commits changes the epoch number format in the following way: * The lower 48 bits of the full 64-bit value represents the current epoch number with fractions * The upper 32 bits contain the current epoch number * The lower 16 bits represents the already elapsed fractions of current epoch(not including current block) Depending on where we are using the epoch number, the unused higher 16 bits are put to different uses: * In block header's epoch field, the higher 16 bits contains the current epoch length * In cell input's since field, the highest 8 bits contains since flag, while the remaining 8 bits are unused. Assuming we are at block number 11555, epoch 50, and epoch 50 starts from block 11000, has a length of 1000. The epoch number for this particular block will then be 281474976713969172, which is calculated in the following way: ``` (1000 << 48) | (50 << 16) | ((2 ** 16) * (11555 - 11000) / 1000) ```
This commit changes the epoch number to a rational number based format. The lower 54 bits of the epoch number field are split into 3 parts(listed in the order from higher bits to lower bits): * The highest 16 bits represent the epoch length * The next 16 bits represent the current block index in the epoch * The lowest 24 bits represent the current epoch number Different from previous solution, with a rational number format the precision can be guaranteed. Assuming we are at block number 11555, epoch 50, and epoch 50 starts from block 11000, has a length of 1000. The epoch number for this particular block will then be 9326559282, which is calculated in the following way: ``` 50 | ((11555 - 11000) << 24) | (1000 << 16) ```
|
bors r+ |
bors bot
added a commit
that referenced
this pull request
Sep 19, 2019
1585: feat: Include fractions in epoch number representations r=xxuejie a=xxuejie This change introduce fractions in 2 places where epoch numbers might be used: * The epoch field in the header * Cell input's since part when using epoch values Here we use a rational number format to represent epoch number. The lower 54 bits of the epoch number field are split into 3 parts(listed in the order from higher bits to lower bits): * The highest 16 bits represent the epoch length * The next 16 bits represent the current block index in the epoch * The lowest 24 bits represent the current epoch number Different from previous solution, with a rational number format the precision can be guaranteed. Assuming we are at block number 11555, epoch 50, and epoch 50 starts from block 11000, has a length of 1000. The epoch number for this particular block will then be 9326559282, which is calculated in the following way: ``` 50 | ((11555 - 11000) << 24) | (1000 << 16) ``` This way, we can alleviate the trouble that CKB uses variable epoch length. The actual contract or dapps can just read this epoch number with fractions and perform numerical operations as normal. Co-authored-by: Xuejie Xiao <xxuejie@gmail.com>
Build succeeded
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change introduce fractions in 2 places where epoch numbers might
be used:
Here we use a rational number format to represent epoch number.
The lower 54 bits of the epoch number field are split into 3
parts(listed in the order from higher bits to lower bits):
Different from previous solution, with a rational number format the
precision can be guaranteed.
Assuming we are at block number 11555, epoch 50, and epoch 50 starts
from block 11000, has a length of 1000. The epoch number for this
particular block will then be 9326559282, which is calculated
in the following way:
This way, we can alleviate the trouble that CKB uses variable epoch
length. The actual contract or dapps can just read this epoch number
with fractions and perform numerical operations as normal.