feat(avm2): avm redesign init #10906

fcarreiro · 2024-12-20T11:08:44Z

This is a redesign of the witgen/proving part of the AVM. There's still a lot of work to be done, but I have to merge at some point to let others contribute :). Most of the content is PoC, not supposed to be real.

We'll eventually have a doc explaining everything, but for now, some highlights:

Architecture

The proving process is now divided in 3 parts:

Simulation (aka event generation): Intrinsically sequential. Executes bytecode and generates packed information (events) that summarize what happened. Examples would be a bytecode decomposition event, memory access event, etc. This part has no dependencies on BB or PIL beyond FF. It also has, in principle, no knowledge of the circuit or columns.
Trace generation: This part is parallelizable. The meat of it is translating events into columns in a (sparse!) trace. It is the glue between events and the circuit. It has knowledge of the columns, but not really about any relation or constrain (**) or PIL.
Constraining: This is parallelizable. It's the actual constraining/proving/check circuit. It's dependent on BB and the (currently) autogenerated relations from PIL. We convert the sparse trace to polynomials.

Possible future standalone simulation

Hints and DB accesses: The simulation/witgen process has no knowledge of hints (so far). We define a DB interface which the simulation process uses. This DB is then "seeded" with hints. This means that in the future it should be possible to switch the DB to a real DB and things should "just work™️".

I think we should try to follow this philosophy as much as possible and not rely on TS hints that we can compute ourselves.

Configurability: Other aspects of simulation are configurable. E.g., we can configure a fast simulation only variant that does no event generation and no bytecode hashing whereas for full proving you would do that (incurring in at least 25ms for a single bytecode hashing).

Philosophy

Dependency injection is used everywhere (without framework). You'll see references stored in classes and may not like it, but it's actually working well. See https://www.youtube.com/watch?v=kCYo2gJ3Y38 as well.

There are lots of interfaces for mocking. Blame C++ 🤷 .

I'm making it a priority to have the right separation of concerns and engineering practices. There's zero tolerance on hacks. If we need a hack, we trigger a refactor.

Testing

Whereas before our tests required setting up everything and basically do full proving or check circuit, now everything can be tested separately. We use a mockist approach (common in C++). Our old tests would take ~0.5s each, now they take microseconds. Simulation, tracegen, and constraining can be tested separate from each other. In particular, you can create tests for constraints at the relation or subrelation level.

Lookups/permutations

Not really supported yet. But you don't need to keep counts for lookups.

TS/C++ communication

AVM inputs are now (de)serialized with messagepack.

(**) It does require lookup/permutation settings.

fcarreiro · 2024-12-20T11:09:06Z

feat(avm2): avm redesign init #10906 👈 (View in Graphite)
chore(avm): extra column information in lookups #10905
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

fcarreiro · 2024-12-20T12:19:35Z

barretenberg/cpp/src/barretenberg/vm2/simulation/execution.cpp

+    const auto [contract_address, _] = memory.get(addr);
+    std::vector<FF> calldata = {};
+
+    auto nested_context = context_provider.make(std::move(contract_address),


We can still choose to make a recursive call to execute here. Depends on how we set up things but I suspect that will be the case. We will likely still need a context stack though, we need to manage it explicitly so that we have the events we need.

jeanmon · 2024-12-20T13:58:26Z

barretenberg/cpp/src/barretenberg/vm2/common/memory_types.hpp

+    U128,
+};
+
+using MemoryAddress = std::size_t;


Not sure if this is the right choice to take size_t as it is a platform-specific type. It is the primitive type to address offsets in vector or array, but in our case if we use a map, we might well use uint32_t or explicitly uint64_t (with explicit memory bound checks)

Good catch, solved!

jeanmon · 2025-01-07T09:56:35Z

barretenberg/cpp/pil/vm2/addressing.pil

+namespace execution(256);
+
+pol commit stack_pointer_val;
+pol commit stack_pointer_tag;


I am not sure if the naming "stack pointer" is fully appropriate compared to sthg not referring stack such as "base address". I understand that it comes from the way the brillig compiler works.

jeanmon · 2025-01-07T10:00:09Z

barretenberg/cpp/pil/vm2/alu.pil

@@ -0,0 +1,16 @@
+namespace alu(256);


This is everywhere and a leftover but the "256" is ignored by our toolchain. IIRC this is the trace length in powdr.
Maybe we should decide how to change as this is misleading.

barretenberg/cpp/pil/vm2/execution.pil

jeanmon · 2025-01-07T10:31:38Z

barretenberg/cpp/src/barretenberg/vm2/avm_api.cpp

+std::pair<AvmAPI::AvmProof, AvmAPI::AvmVerificationKey> AvmAPI::prove(const AvmAPI::ProvingInputs& inputs)
+{
+    // Simulate.
+    info("Simulating...");


I guess that these tracing occurences at info level will be migrated to verbose level?

jeanmon · 2025-01-07T10:44:46Z

barretenberg/cpp/src/barretenberg/vm2/common/map.hpp

@@ -0,0 +1,19 @@
+#pragma once
+
+#include "barretenberg/vm2/common/ankerl_map.hpp"


Excellent to have found this lib!

jeanmon · 2025-01-07T11:14:22Z

barretenberg/cpp/src/barretenberg/vm2/constraining/check_circuit.hpp

+namespace bb::avm2::constraining {
+
+// This is a version of check circuit that runs on the prover polynomials.
+// Better versions could be done, but since this is for debugging only, it is enough for now.


Can you briefly mention the potential improvements?

In principle you may be able to do check circuit over FFs instead of polynomials, and you could maybe do it over the Trace without creating the polynomials. However, tbh, using the polynomials might be the best since it's the closest to "real proving".

barretenberg/cpp/src/barretenberg/vm2/simulation/execution.cpp

jeanmon · 2025-01-07T14:54:27Z

barretenberg/cpp/src/barretenberg/vm2/simulation/execution.cpp

+// TODO: My dispatch system makes me ahve a uint8_t tag. Rethink.
+void Execution::set(ContextInterface& context, MemoryAddress dst_addr, uint8_t tag, MemoryValue value)
+{
+    context.get_memory().set(dst_addr, std::move(value), static_cast<MemoryTag>(tag));


Following clangd warning:

Std::move of the variable 'value' of the trivially-copyable type 'MemoryValue' (aka 'bb::field<bb::Bn254FrParams>') has no effect; remove std::move()

This warning appears to occurences of std::move over a variable of FF type

Ah yeah I have a lot of those, I need to think about it a bit more, but they don't hurt. See https://stackoverflow.com/questions/49241201/is-it-undesirable-to-defensively-apply-stdmove-to-trivially-copyable-types

jeanmon · 2025-01-07T15:41:08Z

barretenberg/cpp/src/barretenberg/vm2/tracegen_helper.hpp

+  public:
+    AvmTraceGenHelper() = default;
+
+    tracegen::TraceContainer generate_trace(simulation::EventsContainer&& events);


Both generate_trace and generate_precomputed_columns can be made static.
Do not change this if you are sure that we will need an object state in AvmTraceGenHelper though.

jeanmon · 2025-01-08T10:47:43Z

barretenberg/cpp/src/barretenberg/vm2/tracegen/lib/README.md

+**Current state**
+
+- Both lookups and permutations are supported.
+  - When you lookup into a precomputed table, you need to define a fast way to find the row for a tuple. See bitwise example.


"you need to define a fast way to find the row for a tuple" Is it meant here an implementation of find_in_dst()
if so, it would be nice mention it.

Done in follow up PR.

jeanmon · 2025-01-08T13:13:45Z

barretenberg/cpp/src/barretenberg/vm2/tracegen/lib/lookup_builder.hpp

+    // We use an RLC for the key instead of the tuple, to save memory.
+    // FIXME: reconsider, what if beta is 0.
+    unordered_flat_map<FF, uint32_t> row_idx;
+    FF beta = FF::random_element();


Add a note that challenges derived like this is very likely insecure. We should probably use the get_challenge() which AFAIK is using Fait-Shamir under the hood to derive challenges.
In any case, this should be reviewed/checks by our crypto guys.

dbanks12

Beautiful!

dbanks12 · 2025-01-06T19:49:35Z

barretenberg/cpp/src/barretenberg/vm2/common/avm_inputs.cpp

+PublicInputs PublicInputs::from(const std::vector<uint8_t>& data)
+{
+    PublicInputs inputs;
+    msgpack::unpack(reinterpret_cast<const char*>(data.data()), data.size()).get().convert(inputs);
+    return inputs;
+}
+
+AvmProvingInputs AvmProvingInputs::from(const std::vector<uint8_t>& data)
+{
+    AvmProvingInputs inputs;
+    msgpack::unpack(reinterpret_cast<const char*>(data.data()), data.size()).get().convert(inputs);
+    return inputs;
+}


dbanks12 · 2025-01-06T21:07:04Z

barretenberg/cpp/src/barretenberg/vm2/constraining/check_circuit.cpp

+            for (size_t r = 0; r < num_rows; ++r) {
+                Relation::accumulate(lookup_result, polys.get_row(r), params, 1);
+            }
+            for (auto r : lookup_result) {
+                if (!r.is_zero()) {
+                    throw std::runtime_error(format("Lookup ", Relation::NAME, " failed."));
+                }
+            }


Why are these two separate loops? For main relations we do this r.is_zero() check inside the loop.

dbanks12 · 2025-01-06T21:11:50Z

barretenberg/cpp/src/barretenberg/vm2/constraining/check_circuit.cpp

+        using Relation = std::tuple_element_t<i, typename AvmFlavor::MainRelations>;
+        checks.push_back([&]() {
+            typename Relation::SumcheckArrayOfValuesOverSubrelations result{};
+
+            for (size_t r = 0; r < num_rows; ++r) {
+                Relation::accumulate(result, polys.get_row(r), {}, 1);


For the bb dummy in the room, what does Relation::accumulate do? Checks the relation at row r and accumulates the result?

Let's take it in a huddle.

dbanks12 · 2025-01-07T18:47:59Z

barretenberg/cpp/src/barretenberg/vm2/generated/relations/alu.hpp

+        {
+            using Accumulator = typename std::tuple_element_t<0, ContainerOverSubrelations>;
+            auto tmp = (new_term.alu_sel_op_add * (FF(1) - new_term.alu_sel_op_add));
+            tmp *= scaling_factor;
+            std::get<0>(evals) += typename Accumulator::View(tmp);
+        }
+        {
+            using Accumulator = typename std::tuple_element_t<1, ContainerOverSubrelations>;
+            auto tmp = ((new_term.alu_ia + new_term.alu_ib) - new_term.alu_ic);
+            tmp *= scaling_factor;
+            std::get<1>(evals) += typename Accumulator::View(tmp);
+        }


Can someone finally explain to me what this is is doing, in particular the Accumulator::View()?

Nobody knows! (the view thing). I can explain over a huddle a bit of the other things.

dbanks12 · 2025-01-07T18:51:44Z

barretenberg/cpp/src/barretenberg/vm2/generated/relations/lookup_dummy_dynamic.hpp

+    template <typename AllEntities> static inline auto inverse_polynomial_is_computed_at_row(const AllEntities& in)
+    {
+        return (in.execution_sel == 1 || in.execution_sel == 1);
+    }


What's going on here with return (s == 1 || s == 1)? Just something silly because it's a dummy class?

Nope. Basically it says that the inverse polynomial will be computed when either the source or target selectors of the lookup are active. It's the same for real lookups.

dbanks12 · 2025-01-08T15:19:48Z

barretenberg/cpp/src/barretenberg/vm2/tracegen/test_trace_container.cpp

+    // Write the shifted values.
+    for (const auto& col : TO_BE_SHIFTED_COLUMNS_ARRAY) {
+        visit_column(col, [&](size_t row, const FF& value) {
+            if (row == 0) {
+                return;
+            }
+            auto shifted = shift_column(col);
+            full_row_trace[row - 1].get_column(shifted.value()) = value;
+        });
+    }


It's not super clear to me why we have so much special logic sprinkled around for "shifted" columns. I guess it's because we don't want to shift things too early, so we hold off until later?

dbanks12 · 2025-01-08T15:21:08Z

barretenberg/cpp/src/barretenberg/vm2/tracegen_helper.cpp

+auto build_precomputed_columns_jobs(TraceContainer& trace)
+{
+    return std::array<std::function<void()>, 2>{
+        [&]() {
+            PrecomputedTraceBuilder precomputed_builder;
+            AVM_TRACK_TIME("tracegen/precomputed/misc", precomputed_builder.process_misc(trace));
+        },
+        [&]() {
+            PrecomputedTraceBuilder precomputed_builder;
+            AVM_TRACK_TIME("tracegen/precomputed/bitwise", precomputed_builder.process_bitwise(trace));
+        },
+    };
+}
+
+void execute_jobs(std::span<std::function<void()>> jobs)
+{
+    parallel_for(jobs.size(), [&](size_t i) { jobs[i](); });
+}


dbanks12 · 2025-01-08T15:22:49Z

barretenberg/cpp/src/barretenberg/vm2/tracegen_helper.cpp

+                [&]() {
+                    ExecutionTraceBuilder exec_builder;
+                    AVM_TRACK_TIME("tracegen/execution",
+                                   exec_builder.process(events.execution, events.addressing, trace));
+                    clear_events(events.execution);
+                    clear_events(events.addressing);
+                },
+                [&]() {
+                    AluTraceBuilder alu_builder;
+                    AVM_TRACK_TIME("tracegen/alu", alu_builder.process(events.alu, trace));
+                    clear_events(events.alu);
+                },


This is saying "process the execution trace and alu trace in parallel. After execution trace is done, free up execution & addressing events. When alu is done, free up alu events?

dbanks12 · 2025-01-08T15:23:17Z

barretenberg/cpp/src/barretenberg/vm2/tracegen_helper.cpp

+    // Now we can compute lookups and permutations.
+    {
+        auto jobs_interactions = std::array<std::function<void()>, 3>{
+            [&]() {
+                LookupIntoBitwise<lookup_dummy_precomputed_lookup_settings> lookup_execution_bitwise;
+                lookup_execution_bitwise.process(trace);
+            },
+            [&]() {
+                LookupIntoDynamicTable<lookup_dummy_dynamic_lookup_settings> lookup_execution_execution;
+                lookup_execution_execution.process(trace);
+            },
+            [&]() {
+                PermutationBuilder<perm_dummy_dynamic_permutation_settings> perm_execution_execution;
+                perm_execution_execution.process(trace);
+            },
+        };
+        AVM_TRACK_TIME("tracegen/interactions", execute_jobs(jobs_interactions));
+    }


Very nice job getting this all nicely executed in parallel!

dbanks12 · 2025-01-08T15:29:59Z

yarn-project/circuits.js/src/structs/avm/avm.ts

+    // TODO: for now I only convert app logic requests?
+    for (const enqueuedCall of this.avmHints.enqueuedCalls.items) {
+      inputs.enqueuedCalls.push({
+        contractAddress: enqueuedCall.contractAddress,
+        sender: new Fr(0), // FIXME
+        args: enqueuedCall.calldata.items,
+        isStatic: false, // FIXME
+      });
+    }


TODO: for now I only convert app logic requests?

You're looping over all of the enqueued call hints though

fcarreiro · 2025-01-11T20:55:47Z

Merge activity

Jan 11, 3:55 PM EST: A user merged this pull request with Graphite.

fcarreiro

Followup cleanup: #11186

fcarreiro · 2025-01-13T10:11:38Z

barretenberg/cpp/src/barretenberg/vm2/constraining/check_circuit.cpp

+        using Relation = std::tuple_element_t<i, typename AvmFlavor::MainRelations>;
+        checks.push_back([&]() {
+            typename Relation::SumcheckArrayOfValuesOverSubrelations result{};
+
+            for (size_t r = 0; r < num_rows; ++r) {
+                Relation::accumulate(result, polys.get_row(r), {}, 1);


Let's take it in a huddle.

fcarreiro · 2025-01-13T10:12:51Z

barretenberg/cpp/src/barretenberg/vm2/constraining/check_circuit.hpp

+namespace bb::avm2::constraining {
+
+// This is a version of check circuit that runs on the prover polynomials.
+// Better versions could be done, but since this is for debugging only, it is enough for now.


In principle you may be able to do check circuit over FFs instead of polynomials, and you could maybe do it over the Trace without creating the polynomials. However, tbh, using the polynomials might be the best since it's the closest to "real proving".

fcarreiro · 2025-01-13T10:13:47Z

barretenberg/cpp/src/barretenberg/vm2/generated/columns.hpp

+
+// The entities that will be used in the flavor.
+// clang-format off
+#define AVM2_PRECOMPUTED_ENTITIES precomputed_bitwise_input_a, precomputed_bitwise_input_b, precomputed_bitwise_op_id, precomputed_bitwise_output, precomputed_clk, precomputed_first_row, precomputed_sel_bitwise


There is a column in pil that is called first_row it has a 1 just on the first row. It's needed to anchor other things.

fcarreiro · 2025-01-13T10:14:18Z

barretenberg/cpp/src/barretenberg/vm2/generated/relations/alu.hpp

+        {
+            using Accumulator = typename std::tuple_element_t<0, ContainerOverSubrelations>;
+            auto tmp = (new_term.alu_sel_op_add * (FF(1) - new_term.alu_sel_op_add));
+            tmp *= scaling_factor;
+            std::get<0>(evals) += typename Accumulator::View(tmp);
+        }
+        {
+            using Accumulator = typename std::tuple_element_t<1, ContainerOverSubrelations>;
+            auto tmp = ((new_term.alu_ia + new_term.alu_ib) - new_term.alu_ic);
+            tmp *= scaling_factor;
+            std::get<1>(evals) += typename Accumulator::View(tmp);
+        }


Nobody knows! (the view thing). I can explain over a huddle a bit of the other things.

fcarreiro · 2025-01-13T10:15:01Z

barretenberg/cpp/src/barretenberg/vm2/generated/relations/lookup_dummy_dynamic.hpp

+    template <typename AllEntities> static inline auto inverse_polynomial_is_computed_at_row(const AllEntities& in)
+    {
+        return (in.execution_sel == 1 || in.execution_sel == 1);
+    }


Nope. Basically it says that the inverse polynomial will be computed when either the source or target selectors of the lookup are active. It's the same for real lookups.

fcarreiro · 2025-01-13T10:20:43Z

barretenberg/cpp/src/barretenberg/vm2/simulation/lib/serialization.cpp

+    assert(pos < bytecode_length);
+    // if (pos >= length) {
+    //     info("Position is out of range. Position: " + std::to_string(pos) +
+    //          " Bytecode length: " + std::to_string(length));
+    //     return InstructionWithError{
+    //         .instruction = Instruction(WireOpCode::LAST_WireOpCode_SENTINEL, {}),
+    //         .error = AvmError::INVALID_PROGRAM_COUNTER,
+    //     };
+    // }
+
+    const uint8_t opcode_byte = bytecode[pos];
+
+    // if (!Bytecode::is_valid(WireOpCode_byte)) {
+    //     info("Invalid WireOpCode byte: " + to_hex(WireOpCode_byte) + " at position: " + std::to_string(pos));
+    //     return InstructionWithError{
+    //         .instruction = Instruction(WireOpCode::LAST_WireOpCode_SENTINEL, {}),
+    //         .error = AvmError::INVALID_WireOpCode,
+    //     };
+    // }
+    pos++;


fcarreiro · 2025-01-13T10:22:00Z

barretenberg/cpp/src/barretenberg/vm2/tracegen/execution_trace.cpp

+        auto operands = ex_event.wire_instruction.operands;
+        assert(operands.size() <= operand_columns);
+        operands.resize(operand_columns, simulation::Operand::ff(0));


We probably don't care but I expect it to be a copy. auto operands hopefully does not magically insert a auto& operands there.

fcarreiro · 2025-01-13T10:22:48Z

barretenberg/cpp/src/barretenberg/vm2/tracegen/lib/README.md

+**Current state**
+
+- Both lookups and permutations are supported.
+  - When you lookup into a precomputed table, you need to define a fast way to find the row for a tuple. See bitwise example.


Done in follow up PR.

fcarreiro · 2025-01-13T10:25:24Z

barretenberg/cpp/src/barretenberg/vm2/tracegen/trace_container.cpp

+void TraceContainer::visit_column(Column col, const std::function<void(uint32_t, const FF&)>& visitor) const
+{
+    auto& column_data = (*trace)[static_cast<size_t>(col)];
+    std::shared_lock lock(column_data.mutex);
+    for (const auto& [row, value] : column_data.rows) {
+        visitor(row, value);
+    }
+}


fcarreiro · 2025-01-13T10:25:31Z

barretenberg/cpp/src/barretenberg/vm2/tracegen/trace_container.cpp

+void TraceContainer::clear_column(Column col)
+{
+    auto& column_data = (*trace)[static_cast<size_t>(col)];
+    std::unique_lock lock(column_data.mutex);
+    column_data.rows.clear();
+    column_data.max_row_number = 0;
+    column_data.row_number_dirty = false;
+}


* master: (329 commits) fix(avm): mac build (#11195) fix: docs rebuild patterns (#11191) chore: refactor Solidity Transcript and improve error handling in sol_honk flow (#11158) chore: move witness computation into class plus some other cleanup (#11140) fix: get_next_power_exponent off by 1 (#11169) chore(avm): vm2 followup cleanup (#11186) fix: underconstrained bug (#11174) refactor: VariableMerkleTree readability improvements (#11165) chore: removing noir bug workaround (#10535) chore(docs): Remove node pages (#11161) git subrepo push --branch=master noir-projects/aztec-nr git_subrepo.sh: Fix parent in .gitrepo file. [skip ci] chore: replace relative paths to noir-protocol-circuits git subrepo push --branch=master barretenberg feat(avm2): avm redesign init (#10906) feat: Sync from noir (#11138) feat: simulator split (#11144) chore: rpc server cleanup & misc fixes (#11145) git subrepo push --branch=master noir-projects/aztec-nr git_subrepo.sh: Fix parent in .gitrepo file. [skip ci] ...

fcarreiro mentioned this pull request Dec 20, 2024

chore(avm): extra column information in lookups #10905

Merged

fcarreiro requested review from dbanks12, IlyasRidhuan, jeanmon and Maddiaa0 December 20, 2024 11:27

fcarreiro commented Dec 20, 2024

View reviewed changes

fcarreiro changed the base branch from fc/pilcom-extra-lookup-info to graphite-base/10906 December 20, 2024 12:40

fcarreiro force-pushed the fc/vm2-prototype branch from 46b4884 to 8e950a6 Compare December 20, 2024 12:42

fcarreiro force-pushed the graphite-base/10906 branch from 161ef17 to ef247d4 Compare December 20, 2024 12:42

fcarreiro changed the base branch from graphite-base/10906 to master December 20, 2024 12:42

fcarreiro force-pushed the fc/vm2-prototype branch from 8e950a6 to aedad34 Compare December 20, 2024 12:42

jeanmon reviewed Dec 20, 2024

View reviewed changes

fcarreiro added the C-avm Component: AVM related tickets (aka public VM) label Jan 6, 2025 — with Graphite App

fcarreiro force-pushed the fc/vm2-prototype branch 3 times, most recently from ddca9ac to 1a2daf1 Compare January 6, 2025 17:38

jeanmon reviewed Jan 7, 2025

View reviewed changes

barretenberg/cpp/pil/vm2/execution.pil Outdated Show resolved Hide resolved

jeanmon reviewed Jan 7, 2025

View reviewed changes

fcarreiro force-pushed the fc/vm2-prototype branch from 2a8f073 to ea64c93 Compare January 7, 2025 11:36

jeanmon reviewed Jan 7, 2025

View reviewed changes

barretenberg/cpp/src/barretenberg/vm2/simulation/execution.cpp Outdated Show resolved Hide resolved

jeanmon reviewed Jan 7, 2025

View reviewed changes

jeanmon reviewed Jan 8, 2025

View reviewed changes

dbanks12 approved these changes Jan 8, 2025

View reviewed changes

IlyasRidhuan approved these changes Jan 9, 2025

View reviewed changes

fcarreiro force-pushed the fc/vm2-prototype branch from fbd5ddf to 6aa00c1 Compare January 10, 2025 13:34

fcarreiro marked this pull request as ready for review January 10, 2025 13:34

fcarreiro force-pushed the fc/vm2-prototype branch 2 times, most recently from 95c1b42 to 6632e7d Compare January 10, 2025 16:43

fcarreiro added 6 commits January 11, 2025 20:18

wip: vm2 prototype

9200db7

use fixed size type for memory address

1984f5c

fix

e983a9c

fix test path

cd32e34

gcc fix

5cda95b

more gcc fixes

9caf394

fcarreiro force-pushed the fc/vm2-prototype branch from 8a5ac30 to 9caf394 Compare January 11, 2025 20:18

fcarreiro merged commit 231f017 into master Jan 11, 2025
49 checks passed

fcarreiro deleted the fc/vm2-prototype branch January 11, 2025 20:55

AztecBot mentioned this pull request Jan 11, 2025

chore(master): Release 0.70.0 #11107

Open

fcarreiro commented Jan 13, 2025

View reviewed changes

		@@ -0,0 +1,19 @@
		#pragma once

		#include "barretenberg/vm2/common/ankerl_map.hpp"

feat(avm2): avm redesign init #10906

feat(avm2): avm redesign init #10906

Conversation

fcarreiro commented Dec 20, 2024 • edited Loading

fcarreiro commented Dec 20, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dbanks12 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fcarreiro commented Jan 11, 2025

Merge activity

fcarreiro left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fcarreiro commented Dec 20, 2024 •

edited

Loading

fcarreiro commented Dec 20, 2024 •

edited

Loading