-
Notifications
You must be signed in to change notification settings - Fork 270
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(3738): AVM basic arithmetic operations for non ff types #3881
Changes from all commits
8ff7315
0258f34
8594bfc
d3f0a13
09a4490
2300f96
87b873b
f74ca13
55fab70
650eec3
31ff1a7
7a64651
115a40a
b9d878f
ee53436
95e9e9f
d365314
a93c9b4
74e8714
8e4f299
0a65b54
fab58b9
1536b28
5d9bda5
c13c702
ecacbbc
5e7570e
5ab8ffc
394d18c
b2ed4f3
41391f6
3feb72e
10eebde
7ce1cf6
ce60c4a
23e2dcd
2fecc75
b0d262d
78457db
14f794c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,21 @@ | ||
This folder contains PIL relations for the AVM. | ||
|
||
Applied heuristic to assess the cost of a relation is given below. | ||
This will be used to determine whether it is worth to merge some | ||
relations into one. | ||
|
||
N_mul = number of mulitplication in the relation | ||
N_add = number of additions/subtraction in the relation | ||
deg = degree of the relation (total degree of the polynomial) | ||
|
||
Relation cost: degree * (N_mul + N_add/4) | ||
|
||
Remark: addition/multiplication with a constant counts as well in the above metrics | ||
Remark: For edge case, we prefer keep a good readability rather than merging. | ||
|
||
Future: There is an optimization in sumcheck protocol allowing to skip some | ||
rows for relations which are not enabled for them (applies when not | ||
enabled over 2 adjacent rows). However, this feature is not yet enabled | ||
in the AVM context. This might change the decision on whether some relations | ||
should be merged or not. Basically, merging relations would decrease the | ||
likelihood to be disabled over adjacent rows. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,201 @@ | ||
include "avm_mini.pil"; | ||
|
||
namespace aluChip(256); | ||
|
||
// ========= Table ALU-TR ================================================= | ||
|
||
// References to main trace table of sub-operations, clk, intermediate | ||
// registers, operation selectors. | ||
// TODO: Think on optimizations to decrease the number of such "copied" columns | ||
pol commit alu_clk; | ||
pol commit alu_ia; // Intermediate registers | ||
pol commit alu_ib; | ||
pol commit alu_ic; | ||
pol commit alu_op_add; // Operation selectors | ||
pol commit alu_op_sub; | ||
pol commit alu_op_mul; | ||
pol commit alu_op_div; | ||
|
||
// Flattened boolean instruction tags | ||
pol commit alu_ff_tag; | ||
pol commit alu_u8_tag; | ||
pol commit alu_u16_tag; | ||
pol commit alu_u32_tag; | ||
pol commit alu_u64_tag; | ||
pol commit alu_u128_tag; | ||
|
||
// 8-bit slice registers | ||
pol commit alu_u8_r0; | ||
pol commit alu_u8_r1; | ||
|
||
// 16-bit slice registers | ||
pol commit alu_u16_r0; | ||
pol commit alu_u16_r1; | ||
pol commit alu_u16_r2; | ||
pol commit alu_u16_r3; | ||
pol commit alu_u16_r4; | ||
pol commit alu_u16_r5; | ||
pol commit alu_u16_r6; | ||
pol commit alu_u16_r7; | ||
|
||
// 64-bit slice register | ||
pol commit alu_u64_r0; | ||
|
||
// Carry flag | ||
pol commit alu_cf; | ||
|
||
// ========= Type Constraints ============================================= | ||
// TODO: Range constraints | ||
// - for slice registers | ||
// - intermediate registers ia and ib (inputs) depending on flag (or inherited from previous ops?) | ||
// - intermediate register ic (in some operations it might be inherited based on ia and ib ranges. To be checked.) | ||
// Carry flag: We will have to constraint to ensure that the | ||
// arithmetic expressions are not overflowing finite field size | ||
// Remark: Operation selectors are constrained in the main trace. | ||
// TODO: Enforce the equivalence check for the selectors between both tables. | ||
|
||
// Boolean flattened instructions tags | ||
alu_ff_tag * (1 - alu_ff_tag) = 0; | ||
alu_u8_tag * (1 - alu_u8_tag) = 0; | ||
alu_u16_tag * (1 - alu_u16_tag) = 0; | ||
alu_u32_tag * (1 - alu_u32_tag) = 0; | ||
alu_u64_tag * (1 - alu_u64_tag) = 0; | ||
alu_u128_tag * (1 - alu_u128_tag) = 0; | ||
|
||
// Operation selectors are copied from main table and do not need to be constrained here. | ||
// TODO: Ensure mutual exclusion of alu_op_add and alu_op_sub as some relations below | ||
// requires it. | ||
// TODO: Similarly, ensure the mutual exclusion of instruction tags | ||
|
||
// ========= Inter-table Constraints ====================================== | ||
// TODO: Equivalence between intermediate registers, clk, type flag, operation | ||
// An ALU chiplet flag will be introduced in main trace to select relevant rows. | ||
|
||
|
||
// ========= EXPLANATIONS ================================================= | ||
// Main trick for arithmetic operations modulo 2^k is to perform the operation | ||
// over the integers and expressing the result as low + high * 2^k with low | ||
// smaller than 2^k. low is used as the output. This works as long this does | ||
// not underflow/overflow the underlying finite field order (u128 multiplication | ||
// will be handled differently). If we want to prove that c = OP(a,b) where OP | ||
// denotes an arithmetic operation modulo 2^k, we can achieve this with two relations: | ||
// (1) low + high * 2^k - OP'(a,b) = 0 | ||
// (2) low - c = 0 | ||
// | ||
// where OP' denotes the same operation as OP but over the integers (not mod 2^k). | ||
// We support u8, u16, u32, u64, u128 types and decompose low into | ||
// smaller bit slices, e.g., 16. For instance, low = s_0 + s_1 * 2^16 + s_2 * 2^32 + ... | ||
// The slices have to be range constrained and there is a trade-off between the | ||
// number of registers and complexity of the range constraints. | ||
// | ||
// Optimization: We will capture the relation (1) for all types under the same umbrella | ||
// by re-using the decomposition used for u128 type for the lower types. | ||
// This works because any larger power of 2^k divides 2^l whenever k <= l. | ||
// To be able to express "low" for u8, we need a 8-bit limb for the lowest | ||
// bits. A bit decomposition covering all types is: | ||
// s8_0 + s8_1 * 2^8 + s16_0 * 2^16 + s16_1 * 2^32 ... + s16_6 * 2^112 + carry * 2^128 - OP'(a,b) = 0 | ||
// where s8_i's are 8-bit registers and s16's 16-bit registers. | ||
// For type uk, we set low to the k-bit truncated part of register decomposition. | ||
// As example, for u32: low = s8_0 + s8_1 * 2^8 + s16_0 * 2^16 | ||
// and for u8: low = s8_0 | ||
// | ||
// TODO: It is open whether we might get efficiency gain to use larger registers for the higher | ||
// parts of the bit decomposition. | ||
|
||
// ============= Helper polynomial terms ============================ | ||
// These are intermediate polynomial terms which are not commited but | ||
// serves to an algebraic expression of commited polynomials in a more concise way. | ||
|
||
// Bit slices partial sums | ||
pol sum_8 = alu_u8_r0; | ||
pol sum_16 = sum_8 + alu_u8_r1 * 2**8; | ||
pol sum_32 = sum_16 + alu_u16_r0 * 2**16; | ||
pol sum_64 = sum_32 + alu_u16_r1 * 2**32 + alu_u16_r2 * 2**48; | ||
pol sum_96 = sum_64 + alu_u16_r3 * 2**64 + alu_u16_r4 * 2**80; | ||
pol sum_128 = sum_96 + alu_u16_r5 * 2**96 + alu_u16_r6 * 2**112; | ||
|
||
// ========= ADDITION/SUBTRACTION Operation Constraints =============================== | ||
// | ||
// Addition and subtraction relations are very similar and will be consolidated. | ||
// For the addition we have to replace OP'(a,b) in the above relation by a+b and | ||
// for subtraction by a-b. Using operation selector values to toggle "+b" vs. "-b" | ||
// makes the deal with the adaptation that the carry term needs to be subtracted | ||
// instead of being added. To sumarize, for the first relation, addition needs to | ||
// satisfy: | ||
// sum_128 + carry * 2^128 - a - b = 0 | ||
// while the subtraction satisfies: | ||
// sum_128 - carry * 2^128 - a + b = 0 | ||
// | ||
// Finally, we would like this relation to also satisfy the addition over the finite field. | ||
// For this, we add c in the relation conditoned by the ff type selector alu_ff_tag. We emphasize | ||
// that this relation alone for FF will not imply correctness of the FF addition. We only want | ||
// it to be satisfied. A separate relation will ensure correctness of it. | ||
// | ||
// The second relation will consist in showing that sum_N - c = 0 for N = 8, 16, 32, 64, 128. | ||
|
||
#[ALU_ADD_SUB_1] | ||
(alu_op_add + alu_op_sub) * (sum_128 - alu_ia + alu_ff_tag * alu_ic) + (alu_op_add - alu_op_sub) * (alu_cf * 2**128 - alu_ib) = 0; | ||
|
||
// Helper polynomial | ||
pol sum_tag = alu_u8_tag * sum_8 + alu_u16_tag * sum_16 + alu_u32_tag * sum_32 + alu_u64_tag * sum_64 + alu_u128_tag * sum_128; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This assumes { alu_u8_tag, alu_u16_tag, alu_u32_tag, alu_u64_tag, alu_u128_tag } are mutually exclusive?
Would perform this check right? but the degree here is very high, is this to be done later? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Exactly! There is already a TODO in the PIL file about ensuring the mutual exclusion. One potential idea is to use pre-defined lookup which flattens a tag value from the main trace into the flags. This lookup is part of AVM code and would ensure this guarantee. Clearly this is work to be done. You can see the relavant TODOs here: |
||
|
||
#[ALU_ADD_SUB_2] | ||
(alu_op_add + alu_op_sub) * (sum_tag + alu_ff_tag * alu_ia - alu_ic) + alu_ff_tag * (alu_op_add - alu_op_sub) * alu_ib = 0; | ||
|
||
// ========= MULTIPLICATION Operation Constraints =============================== | ||
|
||
// ff multiplication | ||
#[ALU_MULTIPLICATION_FF] | ||
alu_ff_tag * alu_op_mul * (alu_ia * alu_ib - alu_ic) = 0; | ||
|
||
|
||
// We need 2k bits to express the product (a*b) over the integer, i.e., for type uk | ||
// we express the product as sum_k (u8 is an exception as we need 8-bit registers) | ||
|
||
// We group relations for u8, u16, u32, u64 together. | ||
|
||
// Helper polynomial | ||
pol sum_tag_no_128 = alu_u8_tag * sum_8 + alu_u16_tag * sum_16 + alu_u32_tag * sum_32 + alu_u64_tag * sum_64; | ||
|
||
#[ALU_MUL_COMMON_1] | ||
(1 - alu_ff_tag - alu_u128_tag) * alu_op_mul * (sum_128 - alu_ia * alu_ib) = 0; | ||
|
||
#[ALU_MUL_COMMON_2] | ||
alu_op_mul * (sum_tag_no_128 - (1 - alu_ff_tag - alu_u128_tag) * alu_ic) = 0; | ||
|
||
// ========= u128 MULTIPLICATION Operation Constraints =============================== | ||
// | ||
// We express a, b in 64-bit slices: a = a_l + a_h * 2^64 | ||
// b = b_l + b_h * 2^64 | ||
// We show that c satisfies: a_l * b_l + (a_h * b_l + a_l * b_h) * 2^64 = R * 2^128 + c | ||
// for a R < 2^65. Equivalently: | ||
// a * b_l + a_l * b_h * 2^64 = (CF * 2^64 + R') * 2^128 + c | ||
// for a bit carry flag CF and R' range constrained to 64 bits. | ||
// We use two lines in the execution trace. First line represents a | ||
// as decomposed over 16-bit registers. Second line represents b. | ||
// Selector flag is only toggled in the first line and we access b through | ||
// shifted polynomials. | ||
// R' is stored in alu_u64_r0 | ||
|
||
// 64-bit lower limb | ||
pol sum_low_64 = alu_u16_r0 + alu_u16_r1 * 2**16 + alu_u16_r2 * 2**32 + alu_u16_r3 * 2**48; | ||
|
||
// 64-bit higher limb | ||
pol sum_high_64 = alu_u16_r4 + alu_u16_r5 * 2**16 + alu_u16_r6 * 2**32 + alu_u16_r7 * 2**48; | ||
|
||
// 64-bit lower limb for next row | ||
pol sum_low_shifted_64 = alu_u16_r0' + alu_u16_r1' * 2**16 + alu_u16_r2' * 2**32 + alu_u16_r3' * 2**48; | ||
|
||
// 64-bit higher limb for next row | ||
pol sum_high_shifted_64 = alu_u16_r4' + alu_u16_r5' * 2**16 + alu_u16_r6' * 2**32 + alu_u16_r7' * 2**48; | ||
|
||
// Arithmetic relations | ||
alu_u128_tag * alu_op_mul * (sum_low_64 + sum_high_64 * 2**64 - alu_ia) = 0; | ||
alu_u128_tag * alu_op_mul * (sum_low_shifted_64 + sum_high_shifted_64 * 2**64 - alu_ib) = 0; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we need to make sure that no other selectors can be set on the row after when There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good input. I also thought about it and came to the conclusion that any wrongly added selectors would add a relation and would probably "over-constrain" the trace. |
||
#[ALU_MULTIPLICATION_OUT_U128] | ||
alu_u128_tag * alu_op_mul * ( | ||
alu_ia * sum_low_shifted_64 | ||
+ sum_low_64 * sum_high_shifted_64 * 2**64 | ||
- (alu_cf * 2**64 + alu_u64_r0) * 2**128 | ||
- alu_ic | ||
) = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 !