This repository helps get an overview of the run times of the consensus code and the recufier code.
Please place code in the appropriate directories, or create them if non-existent.
The lists below keep track of improvements to individual algorithms. If the cycle count changes because Triton VM is updated, or you find a better way of solving a problem, then add a new line to the appropriate table, add a comment to the two relevant lines, and add a counter to the algorithm name, or update the TVM version when appropriate.
Consensus Code
Name
Author(s)
Last edited
TVM version
Tested and Rust-shadowed
Notes
Cycle Count
Asymptotic Runtime
Recufi Code
Name
Author(s)
Last edited
TVM version
Tested and Rust-shadowed
Notes
Cycle Count
Asymptotic Runtime
Other Code Snippets
Name
Author(s)
Last edited
TVM version
Notes
Cycle Count
Hash table height
Asymptotic Runtime
bfe_add
sword_smith
20221208
0.8.0
3
0
hash
sshine, sword_smith
20221208
0.8.0
0
9
u32
Name
Author(s)
Last edited
TVM version
Notes
Cycle Count common
Cycle Count worst-case
Hash table height
Asymptotic Runtime
is_u32
sword_smith
20221208
0.8.0
68
68
0
log_2_floor
sword_smith
20221223
0.9.0
180
354
0
$O(N)$
U32s, size 2
Name
Author(s)
Last edited
TVM version
Notes
Cycle Count common
Cycle Count worst-case
Hash table height
Asymptotic Runtime
incr
sshine, sword_smith
20221208
0.8.0
8
20
0
$O(1)$
decr
sword_smith
20221208
0.8.0
8
20
0
$O(1)$
add
sword_smith
20221208
0.8.0
150
158
0
$O(1)$
sub
sshine, sword_smith
20221208
0.9.0
84
92
0
$O(1)$
lt
sshine, sword_smith
20221209
0.9.0
154
311
0
$O(1)$
powers_of_two_arithmetic_flat
sword_smith
20221208
0.8.0
Adds 17 to cycle count for each increment of the exponent. Range: 11-1090
parameterized over length of list elements,
$N$
, 1-16 B field elements
13 +
$5\cdot N$
13 +
$N$
0
$O(1)$
pop
sword_smith
20221220
0.9.0
parameterized over length of list elements,
$N$
, 1-16 B field elements
17 +
$5\cdot N$
13 +
$N$
0
$O(1)$
MMRA
An MMR is in this context always an MMR accumulator as used in the twenty-first. On the stack it is represented as _ leaf_count peaks where leaf_count is a u64 (two words of u32 values) and where peaks is a pointer into memory where the peaks list is stored.
Name
Author(s)
Last edited
TVM version
Notes
Cycle Count common
Cycle Count worst-case
Hash table height
Asymptotic Runtime
left_child
sshine, sword_smith
20221209
0.9.0
Expensive because u32 arithmetic and no u32 table
354
354
0
$O(1)$
right_child
sshine, sword_smith
20221209
0.9.0
You can call decr for U32<2> instead and save a few cycles
10
22
0
$O(1)$
leftmost_ancestor
sshine, sword_smith
20221209
0.9.0
With a U32 table, a constant time snippet can be made
10953
21060
0
$O(ln(N))$
right_child_and_height
sword_smith
20221216
0.9.0
Cycle count is dominated by leftmost_ancestor
11153
23000
0
$O(ln^2(N))$
?
count_leaves
sword_smith
20221216
0.9.0
Not really needed as leaf_count is a field in MMRA
fennec is an artifact collection tool written in Rust to be used during incident response on *nix based systems. fennec allows you to write a configuration file that contains how to collect artifacts.
Our u64 support is made by stringing two u32 values together and we call this construction U32s<2> after a convention in twenty-first. But maybe u64 would be a more descriptive and familiar name?