when a wallet submits an op, they’ll need to indicate which paymaster (if any) they expect to cover their gas.
If you want to have gasless operations, specify the smart contract that you would like to cover your gas in the UserOperations that's sent (offline) to the bundler
Since the executor is the one paying for gas, not many people would be willing to do that for free. So the new plan is that the wallet contract will hold some ETH, and as part of the executor’s call, the wallet will transfer some ETH to the executor to compensate the executor for any gas used.
the executor pays for the gas because the UserOperations are sent offline to the bundler (usually via an API), thus the executor is/may be the first entity to create an onchain transaction and thus need to pay for gas fees.
Now we'll create the GraphQL interface to access this table. We haven't used this generate command yet (although the scaffold command did use it behind the scenes):
remember to use this command to generate the graphql when you add a new table to the db schema
name: "aTOKEN_NAME",
use the name() function on the AToken to get the name .e.g. Aave Polygon USDC
import aTokenAbi from "./aTokenAbi.json"
use the implementation ABI for the AToken and not the proxy address
const aTokenAddress = "ATOKEN_ADDRESS"
use the proxy address for the ATOKEN
remember to use this nonce and not the wallet's transaction count when getting the nonce for the permit function
In Uniswap V1, trades are always executed at the "best possible" price, calculated at execution time. Somewhat confusingly, this calculation is actually accomplished with one of two different formulas, depending on whether the trade specifies an exact input or output amount. Functionally, the difference between these two functions is miniscule, but the very existence of a difference increases conceptual complexity. Initial attempts to support both functions in V2 proved inelegant, and the decision was made to not provide any pricing functions in the core. Instead, pairs directly check whether the invariant was satisfied (accounting for fees) after every trade. This means that rather than relying on a pricing function to also enforce the invariant, V2 pairs simply and transparently ensure their own safety, a nice separation of concerns. One downstream benefit is that V2 pairs will more naturally support other flavors of trades which may emerge, (e.g. trading to a specific price at execution time).At a high level, in Uniswap V2, trades must be priced in the periphery. The good news is that the library provides a variety of functions designed to make this quite simple, and all swapping functions in the router are designed with this in mind.
In Uniswap V2, trades are executed without a central pricing function. Instead, the system checks whether the price of the trade is correct after the trade has been executed by checking the "invariant". The invariant is the relationship between the input and output amounts of a trade, and it ensures that the price of the trade is fair and reasonable.
For example, if the input amount is 1 ETH and the output amount is 100 tokens, the invariant would state that the price of the tokens should be 100 tokens/1 ETH. If the actual price of the tokens at the time of the trade is different from this, the trade would not be executed.
This approach allows for more flexibility and simplicity for users, as it allows for a more direct way to verify the price of a trade. It also separates concerns, in that the pricing function is not responsible for ensuring the safety of the trade, but just ensuring that the price is fair. Additionally, this approach also enables the system to more easily support other types of trades that may emerge in the future, such as trading at a specific price at the time of execution.
In summary, in Uniswap V2, the system ensures the fairness of price by checking the invariant after the trade is executed, instead of using a central pricing function. This allows for more flexibility, simplicity and safety for the users, and also enables the system to adapt to new trade types in future.
1st prize: 20K MINA
this is mine
embedding the ZkProgram within a SmartContract method
So does this mean - creating the zkProgram outside of the smart contract code - generate the steps with the right responses - store the output of the above as a variable which is then referenced in the smart contract - when the user performs the steps and it has to be verified with the blockchain. the smart contract is invoked and it verifies that the steps return the same output as the zkProgram?
proof: SimpleProgram.Proof
pass the proof as input to another method
the developer can choose the shape of the public input to all the methods
what does it mean to change the shape?
// we fetch the on-chain commitment
the onchain committment is the root of the tree
leaderboardZkApp.commitment.get().assertEquals(Tree.getRoot());
why was this necessary here?
doProofs
when is doProofs false?
let witness = new MerkleWitness(w);
we need this to know example where the name is in the tree
await makeGuess('Bob', 0n, 22);
in reality, how will we know what position bob is in the tree? as the makeGuess function requires the index to be passed in
0n
is this the index or position of the name in the tree, why the 'n'?
we check that the account is within the committed Merkle Tree
why does the account have to be in the merkle tree? Is it because only certain accounts are allowed to guess? So it's just specific to this app's goals and not necessary?
let target = Field( '17057234437185175411792943285768571642343179330449434169483610110583519635705' );
is this actually a secret or is this public? I guess the fact that it's a hash means it doesn't matter as it uses asymmetric cryptography which means that they can't find the original number (22) from which the hash came from?
let bob = new Account(Local.testAccounts[0].publicKey, UInt32.from(0));
alternatively, can this be the data that you get from IPFS?
I think I read that a smart contract can only have 8 state variables - can this be extended with custom data types?
assertEquals(true) at the end means that it will be impossible to generate a valid proof unless signerPublicKey is equal to one of the pre-approved users.
remember that your smart contract creates the prover function. the prover function generates the zk proof that is required for the verifier (mina blockchain) to determine whether the transaction is valid.
The Mina network will reject any transaction sent to a zkApp account that doesn’t include a valid zero-knowledge proof for that account.
This validator is responsible for creating a new block and sending it out to other nodes on the network. Also in every slot, a committee of validators is randomly chosen, whose votes are used to determine the validity of the block being proposed.
so this means that even though when the merge occurred, there were two addresses were responsible for validating 46% of the network, https://twitter.com/santimentfeed/status/1570339602346684416, it would be very risky for them to propose illegitimate blocks as the committee of validators would vote that the block is illegitimate and a portion of that validators stake will be slashed. How much is slashed though?
Telegram
on admins can message in this group and discord developers channel isn't listed here
blockies
this is an package which was installed when we did npm install at the start of this section. https://www.npmjs.com/package/blockies-identicon A tiny library for generating blocky identicons.
data-bs-target
data-target is used by bootstrap and it is part of their javascript package so you don't have to write the code to link the two. This links the button to the modal so that when you click the button the modal appears.
emit
the zero-account is just a special case used to indicate that a new contract is being deployed. It is literally '0x0' set to the to field in the raw transaction.
event
events allow us to write "logs" to a blockchain in a way that's more searchable and gas efficient than saving to public variables. the logs can't be accessible by smart contracts but gives information about what's happening. If you run a node, you can listen to events and perform an action based on it, such as updating your front end
constructor
a constructor is used to initialize the state variables of a smart contract. constructor code is executed once when a contract is created and it is used to initialize contract state.
Because the Solidity language can be used by any EVM-compatible blockchain, the entire standard can be reproduced on Celo with little extra work.
an interface in a programming language is an abstraction which is meant to be inheritted by other objects that are of the same type. for example a car object would all have functions such as break, drive, reverse and properties such as mileage etc. so similarly, with the ERC20 interface, all ERC20 tokens (or shall we say fungible tokens built on Ethereum compatible blockchains) will have the same properties and methods. However, some tokens may extend the interface and add methods that are unique to that particular type of token. Just like an new type of car - such as an electric car will have other properties related to electricity and charging.
payable
https://solidity-by-example.org/payable Functions and addresses declared payable can receive ether / the native blockchain token into the contract
mapping
the way that you decide to organize data in your code is called a data structure, a mapping is a type of data structure which is a collection of key-value pairs.
memory
The Ethereum Virtual Machine has three areas where it can store data: storage, memory and the stack. Each account has a data area called storage, which is persistent between function calls and transactions.
The second data area is called memory, of which a contract obtains a freshly cleared instance for each message call.
The EVM is not a register machine but a stack machine, so all computations are performed on a data area called the stack.
So in this case, using memory is appropriate because we don't need to the value to persist between function calls, as this is an opportunity for the user to keep entering whatever input they like.
function
functions take in input, may do some modifications and may or may not return an output.
for functions that simply return info, does not does not modify anything, the keyword view is used.
By declaring a function as view, you are promising the compiler that the function does not modify state. The EVM doesn't check though.
You then use the returns keyword followed by the variable type and storage location. Because the info returned only needs to be temporary then the memory storage location is used.
internal
notice the variable visibility here. The variable within the smart contract is internal which means that the product variable can only be accessed from within the contract and derived contracts.
where as the function parameter variable has the type memory, hey only persist while a function is called, and thus are temporary variables that cannot be accessed outside this scope. they only persist while a function is called, and thus are temporary variables that cannot be accessed outside this scope
function
Functions are the executable units of code. Functions are usually defined inside a contract, but they can also be defined outside of contracts.
product
State variables are variables whose values are permanently stored in contract storage.
_product
the underscore is just a naming convention in solidity you can start variable names with underscores or letters only. Some developers use the underscore as a naming convention for e.g. for function names, for private variables, for function parameters etc.