oxheadalpha / smart-contracts Goto Github PK
View Code? Open in Web Editor NEWA library of smart contracts
License: MIT License
A library of smart contracts
License: MIT License
Move implementation from simple_admin to multi_token_impl
┆Created By: tqbot
From Tom Jack
"make the to_ field have type or address key_hash
, make the 'safety check' required for Left
, but skipped (obviously) for Right.
"
┆Created By: tqbot
Some prefer to use non-imperative/non-functional syntax for their contracts and it would be really awesome to have this whole repo available in all four flavors of LIGO instead of just CameLIGO, that way no one is left out.
I would say if we had to go in order of importance:
┆Created By: Igor Tkach
it's still not quite clear how lazy data migration works in your Scenario 3. SC2 can call SC1's universal entrypoint with a lambda but what does that achieve? Sounds like SC2 wants to get SC1's data but entrypoints do not return values, so... now what?
┆Created By: tqbot
DS token will call forwarder to run checks with from, to, and amount of tokens
have forwarder expose: whitelist, expiration date, total amount that can be forwarded
need to change parameters during lifetime? (assume so)
┆Created By: Michael Klein
Hello, I see there is a package.json
in the repo. By adding a name and a version number, users will be able to fetch directly the repo as a package which can be useful when compiling for apps.
Is that something you will consider adding?
Many thanks for all the work!
Here is what's needed for FA1.4:
Then, we'll do a gas benchmark between FA2 (a.k.a MAC) and FA1.4.
┆Created By: Julien Hamilton
Upon trying to run the tests in eg single_asset
, there is an issue with the paths during the importing of different .mligo
files:
ERROR: test_transfer_to_receiver (test_fa2.TestTransfer)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/owen/tezos/fa2-demo/smart-contracts/single_asset/tezos_fa2_single_tests/test_fa2.py", line 181, in setUp
super().setUp()
File "/home/owen/tezos/fa2-demo/smart-contracts/single_asset/tezos_fa2_single_tests/test_fa2.py", line 39, in setUp
self.orig_contracts()
File "/home/owen/tezos/fa2-demo/smart-contracts/single_asset/tezos_fa2_single_tests/test_fa2.py", line 58, in orig_contracts
self.fa2 = self.orig_fa2(ligo_fa2)
File "/home/owen/tezos/fa2-demo/smart-contracts/single_asset/tezos_fa2_single_tests/test_fa2.py", line 108, in orig_fa2
ptz_storage = ligo_fa2.compile_storage(ligo_storage)
File "/home/owen/tezos/fa2-demo/smart-contracts/single_asset/tezos_fa2_single_tests/ligo.py", line 76, in compile_storage
michelson = self._ligo_to_michelson_sanitized(command)
File "/home/owen/tezos/fa2-demo/smart-contracts/single_asset/tezos_fa2_single_tests/ligo.py", line 102, in _ligo_to_michelson_sanitized
michelson = self._ligo_to_michelson(command)
File "/home/owen/tezos/fa2-demo/smart-contracts/single_asset/tezos_fa2_single_tests/ligo.py", line 97, in _ligo_to_michelson
raise Exception(msg)
Exception: in file "fa2_single_token.mligo", line 9, characters 9-37
Preprocessing error in file "fa2_single_token.mligo", line 9, characters 9-37:
File "../fa2/fa2_interface.mligo" to include not found.
Here I've installed the smart-contracts directory as a submodule within /home/owen/tezos/fa2-demo/
.
I had first tried running the tests in smart-contracts/nft_assets
, but had some Python errors there too, in tezos_fa2_nft_tests/test_fa2.py
where the reference to pytezos.rpc.errors
must've been out of date − happy to submit a PR for that once I can get these tests running :) (same LIGO path issue).
The errors occur as soon as relative paths are used, eg in fa2_single_token.mligo
:
…
#include "../fa2/fa2_interface.mligo"
I was invoking the test from ~/tezos/fa2-demo/smart-contracts/single_asset
┆Created By: Igor Tkach
How exactly do I reference the entry points of fa2_nft_asset.mligo
?
I can manage to compile with
ligo compile-contract --michelson-format=json nft_assets/ligo/src/fa2_nft_asset.mligo nft_asset_main > contract.json
But setting up even just one dry-run command seems to take a really intense amount of knowledge? I can't seem to figure out how to hit the Tokens()
entry point for example.
$ ligo run dry-run nft_assets/ligo/src/fa2_nft_asset.mligo -e nft_asset_main
Invalid command line argument.
The provided entrypoint is not found in the contract.
It's arcane how to to use the contract's API/entry points.
From Tom Jack:
"now, here's my impersonation example: I call the erc1155 Balance_of_batch
method. I pass a lambda which generates a On_erc1155_batch_received
transfer to the victim erc1155_token_receiver
the erc1155 thinks this is an innocent "view" operation, but it is not"
"the correct way is for the caller of Balance_of_batch
to pass a (balance_request * nat list)
contract instead of the lambda, and for the erc1155 to (carefully) construct the TRANSFER_TOKENS
(or perhaps address instead of contract, unclear).
this is still somewhat tricky, you need to ensure that the type (balance_request * nat list)
cannot be used for "impersonation"
e.g. is incompatible with the types for On_erc1155_batch_received
"
┆Created By: tqbot
be able to add operators for whitelisted implicit accounts
┆Created By: tqbot
[ DRAFT REQUIREMENTS ] --> will be reviewed and improved with Andrew.
We need 2-of-6 multisig, but it's not regular one - it's like 3 families, 3 pairs with some restrictions, like two husbands can't get together and sign.
Take existing multisig contract and replace signature requirement with sender + parameter types - and combine with regular multisig for signing by family (couple).
However, formal verification tooling doesn't support multi-contract interactions, so preferably these two need to be combined into one contract
Plan
┆Created By: Julien Hamilton
Doc here:
https://docs.google.com/document/d/1azyHluaN-fdKKMlIEzf-dHJrcy6Fa_xQbB1FHt9pzrM/edit?ts=5e4ff46e
Issue here: #29
(couldn't find it in Asana)
┆Created By: Michael Klein
Although on-chain events are on their way, wallet / indexer developers have requested integration into the the TZIP-16 metadata of these reference contracts
┆Created By: [email protected]
Milestones for MAC specifications
Design / Implementation
Integration coverage
┆Created By: Julien Hamilton
It's unclear how you mint two different singular NFTs on the same contract with different metadata, which is usually the case for NFT contracts. The token_metadata
endpoint is also a little arcane, as it asks for a lambda as the first parameter and I'm not sure what sort of function it expects.
Everything is catered toward a range of NFT IDs with the same metadata.
(* range of nft tokens *)
type token_def =
[@layout:comb]
{
from_ : nat;
to_ : nat;
}
The test cases only show one case where you want to mint two NFTs with the same metadata:
https://github.com/oxheadalpha/smart-contracts/blob/master/nft_assets/tezos_fa2_nft_tests/test_fa2.py#L132-L153
So my question is how do I do two?
Is this how I would do two separate ones?
self.fa2.mint_tokens(
{
"metadata": token_metadata1,
"token_def": {
"from_": 0,
"to_": 1,
},
"owners": [owner1_address],
}
self.fa2.mint_tokens(
{
"metadata": token_metadata2,
"token_def": {
"from_": 1,
"to_": 2,
},
"owners": [owner1_address],
}
Furthermore, how do I check the metadata for a single token with token_metadata
?
(**
Implementation of the FA2 interface for the NFT contract supporting multiple
types of NFTs. Each NFT type is represented by the range of token IDs - `token_def`.
*)
What does "type" mean? It's unclear. A non-fungible token is 1-1 and therefore it's always a unique type.
For now the same simple_admin
extension is used for both single asset and multi assets implemenations. That means that all tokens of a multi asset contract will be paused at once.
It could be very usefull to have a more fine grained control : make each token pausable independently.
I guess %pause
could accept a list (pair nat bool)
if we want to batch the operation.
Open to feedback, of course :)
"if the spec were written in Michelson, as it should be, and used "%to", Cameligo would be incapable of meeting the spec..."
┆Created By: tqbot
Review FA2 (https://gitlab.com/tzip/tzip/-/blob/tzip12-draft/proposals/tzip-12/tzip-12.md) specification and write up comments on any parts that are unclear or hard to understand. This will allow us to vet the current documentation and make it clearer for external developers
┆Created By: [email protected]
from comments on this schema copy: https://hackmd.io/9Oua5hLATE23Na9jCJtTnA
to_
, because "to" is an unused reserved word in Cameligo, due to a nonsensical attempt to make it "as close as possible to OCaml".Regarding differences w/ ERC-1155 version:
on_erc1155_*
cannot be invoked?to_
is a smart contract which does not implement the expected interface?to_
is an address with an entry point, "KT1...%foo"?to_
field have type or address key_hash
, make the 'safety check' required for Left, but skipped (obviously) for Right."┆Created By: tqbot
Hello,
I want to call the Balance_of
entrypoint for a standard FA2 contract in a CameLIGO unit test (or it's "implementation" get_balance
).
I am trying to formulate the correct balance_of_request.callback
parameter, but the continuation-passing style is giving me trouble - I cannot conjure up the correct incantation.
Below is the test in development. Notice that I typed all the parameters, and broke everything down completely, to isolate completely the error.
The problem I have is only with the callback
parameter ("Cannot unify ..."). I have tried a number of things, but I cannot get the right incantation.
My last effort has been trying to pass a fun
to the callback, because I thought it might require a fun going from balance_of_response list
to contract
. It is a unique signature amongst all the other ones with which I have successfully worked.
let test_call_get_balance =
let addr,_,_ = Test.originate main {initial_storage with admin = admin} 0tez in
let contract = (Test.to_contract addr) in
let balance_request: balance_of_request = {owner = alice; token_id = 0n} in
let requests: balance_of_request list = [balance_request] in
// OR: let requests: balance_of_request list = [{owner = alice; token_id = 0n}] in
// !!Trying to formulate balance_of_request.callback parameter here!!
// This is "just" another attempt, I am not sure how to reconcile this with CPS
let callback = fun(l: balance_of_response list): contract ->
let _printList = Test.log("Got list: ", l) in
contract
in
let balance_param: balance_of_param = ({ requests = requests; callback = callback}) in
// And finally call get_balance (alternatively the Balance_of entrypoint)
let balance_of_response: balance_of_response = get_balance(requests) in
Test.log("Alice's balance is:", balance_of_response.balance)
What is the correct incantation such that I can get the above to pass? You can see what I'm trying to do, I hope?
I will also take this opportunity to thank you very much for the significant value I have derived from this repository.
Cheers!
Edward Garson
Developer Evangelist @ ECAD Labs
┆Created By: Igor Tkach
┆Created By: Igor Tkach
With the recent protocol upgrades the current FA2 standard cant keep up and is in terms of actuality outdated. Is there a plan to update the FA2 standard? Or no plans at all and FA3 will be published like in the discussion here?
https://forum.tezosagora.org/t/fa2-1-fa3-its-time/3704/16
Hello!
The multi asset spec mentions "safety check" for token receivers in a couple places, and also uses the language "MUST implement" -- in particular regarding the multi_token_receiver
interface.
What is the meaning of this, exactly? It is not very clear.
The multi_token_receiver
interface is defined like this as a LIGO variant:
type multi_token_receiver =
| On_multi_tokens_received of on_multi_tokens_received_param
The variant has only one case, so in LIGO, the type multi_token_receiver
is compiled the same way as on_multi_tokens_received_param
-- as a tree of pair
types.
(I think, at the moment, you should not write Michelson interface specifications using LIGO types!)
In the draft LIGO implementation, we have code like this:
let receiver : multi_token_receiver contract =
Operation.get_contract param.to_ in
(Recall to_ : address
in the transfer parameter.)
In the compiled Michelson, this shows up as:
CONTRACT (pair (pair (list (pair nat nat)) bytes) (pair (option address) address))
IF_NONE { PUSH string "bad address for get_contract" ; FAILWITH } {} ;
This seems to have some interesting consequences.
Most importantly, I believe this means that passing a to_
address with an entry point (intending to transfer to a receiver who implements %on_multi_tokens_received as well as other entrypoints) will result in locked tokens. Token receivers will require proxy contracts,
It is possible I am confused? It is late.
┆Created By: tqbot
Contract spec should describe motivation behind choices for functionality, entry point names and parameter types.
┆Created By: tqbot
┆Created By: tqbot
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.