-
Notifications
You must be signed in to change notification settings - Fork 234
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: internal keyword + lending contract and tests #978
Conversation
056ace0
to
7aa3e02
Compare
✅ Deploy Preview for preeminent-bienenstitch-606ad0 canceled.
|
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.
Looks good, most of what i have is nits and possible improvements we can make in next steps.
@@ -32,14 +34,15 @@ template <typename NCT> struct FunctionLeafPreimage { | |||
using uint32 = typename NCT::uint32; | |||
|
|||
uint32 function_selector = 0; | |||
boolean is_internal = false; |
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.
This being almost the same as function_data
makes me think that the types should maybe be unified
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.
Possibly, 3 are overlapping. But the function data is accesible inside noir as well, so maybe the leaf should include the function data: leaf = {function_data, vk_hash, acir_hash}
. Seems more intuitive to have the is_constructor
stored in the leaf as well. Don't recall how we right now are ensuring the constructors are not rerun @iAmMichaelConnor.
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.
I like the sounds of that
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.
I think perhaps the difference between function_data
and function_leaf_preimage
(at least, when things were initially designed... having quickly looked back at the diagram, which is basically an extension of my memory at this point)... is...
function_data
is information about the function you wish to call, which becomes part of a tx_request. It's separate from any deployment information. Perhaps it should be renamed to target_function
or entrypoint_function
or something. Given this information, a node which has already synced can lookup the rest of the function's info (vk_hash, acir_hash, etc).
function_leaf_preimage
is data required to prove existence of the function in the contracts tree. Some of that data comes from function_data
, and some of that data is grabbed by the rpc server.
Some of this is faint memories, so I could be wrong, but I believe their separation was intentional.
Re storing is_constructor
in the leaf. In the initial design, the constructor isn't included as a leaf in the tree (because it never needs to be called after deployment); so the constructor's information is only included in the constructor_hash
which is included in the contract's address. I'm not sure if that's still the case in the code. I intend to write lots of specs soon, and we'll review all this.
Don't recall how we right now are ensuring the constructors are not rerun
We emit a nullifier = h(contract_address). You can only call a constructor at the time of deployment, and at deployment the nullifier gets emitted, so there's no way to call a constructor twice.
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.
sounds good, it can stay as is!
@@ -5,6 +5,8 @@ | |||
#include "aztec3/utils/types/convert.hpp" | |||
#include "aztec3/utils/types/native_types.hpp" | |||
|
|||
#include "barretenberg/common/serialize.hpp" |
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.
Why was this not neede before?
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.
Probably not needed actually, but just leftovers from some fiddling in the middle.
@@ -192,6 +192,15 @@ void common_validate_inputs(DummyBuilder& builder, KernelInput const& public_ker | |||
builder.do_assert(public_kernel_inputs.public_call.bytecode_hash != 0, | |||
"Bytecode hash must be non-zero", | |||
CircuitErrorCode::PUBLIC_KERNEL__BYTECODE_HASH_INVALID); | |||
|
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.
Can you add a cpp test testing this code path, similarly for the other assert
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.
Yep, will do. It's tested in the TS as well.
@@ -388,7 +388,7 @@ describe('Private Execution test suite', () => { | |||
expect(result.callStackItem.publicInputs.returnValues[0]).toEqual(new Fr(initialValue + privateIncrement)); | |||
}); | |||
|
|||
it('parent should call child', async () => { | |||
it.only('parent should call child', async () => { |
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.
bonk
@@ -293,11 +293,12 @@ export class PrivateFunctionExecution { | |||
targetArgs: Fr[], | |||
callerContext: CallContext, | |||
): Promise<PublicCallRequest> { | |||
const targetAbi = await this.context.db.getFunctionABI(targetContractAddress, targetFunctionSelector); |
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.
nicely done
await tx.isMined(0, 0.1); | ||
const receipt = await tx.getReceipt(); | ||
expect(receipt.status).toBe(TxStatus.MINED); | ||
logger('Depositing 🥸 : 💰 -> 🏦'); |
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.
glorious
yarn-project/end-to-end/package.json
Outdated
@@ -11,7 +11,7 @@ | |||
"clean": "rm -rf ./dest .tsbuildinfo", | |||
"formatting": "run -T prettier --check ./src && run -T eslint ./src", | |||
"formatting:fix": "run -T prettier -w ./src", | |||
"test": "DEBUG='aztec:*,wasm' NODE_NO_WARNINGS=1 node --experimental-vm-modules $(yarn bin jest) --runInBand --passWithNoTests --testTimeout=15000", | |||
"test": "DEBUG='aztec:*e2e*,wasm' NODE_NO_WARNINGS=1 node --experimental-vm-modules $(yarn bin jest) --runInBand --passWithNoTests --testTimeout=15000", |
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.
was this commited on purpose?
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.
Whoops. Will fix.
|
||
let asset = storage.assets.at(0); | ||
|
||
let tot = asset.read(); |
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.
what does tot stand for?
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.
Totals. Normally, would refer to it simply as the asset, but that gets somewhat weird with our storage accessing, maybe the asset
becomes asset_loc
and then I can do it.
|
||
let (_callStackItem, mut context) = PublicCallStackItem::call( | ||
inputs.call_context.storage_contract_address, | ||
1462609836, |
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.
damn we really need the sig utilities
secret: Field, | ||
} | ||
|
||
impl Account { |
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.
this file could use some annotations, im not super familiar with lending protocols its hard to decipher the abbreviations
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.
The lending protocol part of it is a bit shit right now, as there was not enough reads/write to do it proper. But just enough to hit the use for internal
and stuff.
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.
Looks good, most of what i have is nits and possible improvements we can make in next steps.
@@ -388,7 +388,7 @@ describe('Private Execution test suite', () => { | |||
expect(result.callStackItem.publicInputs.returnValues[0]).toEqual(new Fr(initialValue + privateIncrement)); | |||
}); | |||
|
|||
it('parent should call child', async () => { | |||
it.only('parent should call child', async () => { |
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.
think this got included by mistake
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.
lgtm overall, i dont think the bb build system should be changed here though. One that is resolved lets send it
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.
Should the build system be changed in this pr?
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.
Nope, should be fixed now.
@@ -32,14 +34,15 @@ template <typename NCT> struct FunctionLeafPreimage { | |||
using uint32 = typename NCT::uint32; | |||
|
|||
uint32 function_selector = 0; | |||
boolean is_internal = false; |
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.
sounds good, it can stay as is!
@@ -38,6 +39,7 @@ exports[`should compile the test contract 1`] = ` | |||
{ | |||
"bytecode": "00000000020000000000000001000000010000000100000000000000000100000030644e72e131a029b85045b68181585d2833e84879b9709143e1f593f000000001000000000000000000000000000000000000000000000000000000000000000000002a", | |||
"functionType": "open", | |||
"isInternal": undefined, |
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.
Im assuming this will get fixed over time, and as this folder is not under active development, this is fine for now
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.
lgtm
Description
Adding checks to ensure that
isInternal
as introduced in noir-lang/noir#1873 behaves as expected.Briefly, if
isInternal = true
then only the contract itself should be able to execute the call. There is a lending protocol example that uses this such that there are both a private and public entry with most logic being in the same internal function.This PR are only strictly enforcing the check for private functions, as public where not checking the contract tree (see #1200 for more info).
Checklist: