oxheadalpha / smart-contracts Goto Github PK

[ 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.

• Husband-wife couple will will be signing all transactions
• But what if one spouse dies?
• Second familty comes in (2nd tier)
• But then recovery kicks in and it goes back to 3-tier set up (failed couple is replaced)
• Third tier is only coming into play in a catastrophic scenario, apocalypse
• This process is designed so that private keys never need to be restored

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

• Michael can do at least prototype and demo it. A couple of weeks timeframe should be ok and Michael should be able to find time
• In a couple of weeks time Ken wants to be able to go through some testing/demo for this "multi-stage multisig".

┆Created By: Julien Hamilton

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

• Get rid of ERC1155 in the names and use "multi-assets" something
• More sane entry point names
• leave only batch version of transfer and balance_of
• add_operator/remove_operator/is_operator

┆Created By: tqbot

┆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.

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 :)

┆Created By: Igor Tkach

Move implementation from simple_admin to multi_token_impl

┆Created By: tqbot

Here is what's needed for FA1.4:

• Sender / Receiver hooks
• Reference Implementation / Specifications
• Compatibility with FA1.2
• Granularity as discussed
• TZIP

Then, we'll do a gas benchmark between FA2 (a.k.a MAC) and FA1.4.

┆Created By: Julien Hamilton

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

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:

1. JsLIGO (very beginner friendly)
2. PascaLIGO (the default on TezosAcademy)
3. ReasonLIGO (I don't see many devs using this version)

Milestones for MAC specifications

Design / Implementation

1. Complete current specifications, test and demo (MVP)
2. Separate interface versions:
   one lightweight version without receiver (e.g. especially suited to gaming)
   one with receiver
3. Explore total balance/supply at implementation vs. specification
4. Permissioning
   Whitelisting / token permissions a la ERC-1404
5. Token types (high level)
   Fungible, transferrable (e.g. tokenized equity, tickets)
   Fungible, non-transferrable (e.g. reputation points / achievement score in a game)
   Non-fungible, transferrable (e.g. artwork)
   Non-fungible, non-transferrable (e.g. identity, achievement badges)

Integration coverage

1. Custody
2. Wallet (NFT/FTs)
3. Exchange
4. Reference UI (Philip D)

┆Created By: Julien Hamilton

┆Created By: Igor Tkach

Although on-chain events are on their way, wallet / indexer developers have requested integration into the the TZIP-16 metadata of these reference contracts

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

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]

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!

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

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

"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

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

from comments on this schema copy: https://hackmd.io/9Oua5hLATE23Na9jCJtTnA

• "if the spec were written in Michelson, as it should be, and used "%to", Cameligo would be incapable of meeting the spec"
• "What is the point of having both batch and single versions of the entry points? Why not only the batch version?"
• "funny that the interface will have 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:

• If to_ contract does not implement entry point On_erc1155_received, the transaction MUST skip safety check.
• What exactly does "skip safety check" mean? The token contract should proceed even though on_erc1155_* cannot be invoked?
• Doesn't this defeat the designed purpose of the safety check? What if:

1. The to_ is a smart contract which does not implement the expected interface?
2. The to_ is an address with an entry point, "KT1...%foo"?

• "It seems like a justification for this choice is described in the "differences": "Michelson does not provide API to distinguish between implicit (EOA) and originated addresses". It is true that Michelson is missing some instruction for this. In the meantime, here is just one possible alternative, I am sure there are more: 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

Contract spec should describe motivation behind choices for functionality, entry point names and parameter types.

┆Created By: tqbot

be able to add operators for whitelisted implicit accounts

┆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

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

┆Created By: [email protected]

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

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.