Git Product home page Git Product logo

zrc's Issues

ZRC#0

Comment tracker for ZRC#0

ZRC contracts must have unique names for callback transitions

For example, the ZRC-1 and ZRC-2 contracts share the same name for a callback, namely TransferSuccessCallBack.

This prevents using both of these ZRCs in one user contract because that forces the user to have two TransferSuccessCallBack transitions with different type signatures.

Reference contracts naming scheme

As of now the reference-contracts directory looks like this:

.
├── FungibleToken-Mintable.scilla
├── FungibleToken-Operator.scilla
├── FungibleToken.scilla
├── MetaFungibleToken.scilla
├── multisig_wallet.scilla
├── nonfungible-token.scilla
├── style-guide.md
└── zrc6.scilla

and it's not clear what, for instance, nonfungible-token.scilla's ZRC number is.

One possible proposal could be to prepend all the contract names with their ZRC index like so:

.
├── zrc2_FungibleToken-Mintable.scilla
├── zrc2_FungibleToken-Operator.scilla
├── zrc2_FungibleToken.scilla
├── zrc3_MetaFungibleToken.scilla
├── zrc4_Multisig-Wallet.scilla
├── zrc1_NonFungibleToken.scilla
├── style-guide.md
└── zrc6_NonFungibleToken.scilla

ZRC#3

Comment Tracker for ZRC#3

ZRC#3 extends ZRC#2 to enable a more equitable check-teller transaction pattern, as an alternative or supplement to the omnipotent operator.

Pattern/anti-pattern guide

We could use a guide to patterns/antipatterns in Scilla.

Examples:

  • Don't use ping-pong between contracts. Instead, attempt to complete everything in one contract before invoking transitions on the other contract. If the second contract for some reason discovers a problem, then throw an exception (or otherwise cause an execution error), so that the entire chain of invocations are rolled back.

  • Avoid using the size operation, as it requires reading the entire map from the state. Instead, manually maintain a size counter, and use a dedicated procedure to update the map and the counter together, so that they are always kept in sync.

ZRC#1

Comment tracker for ZRC 1.

Transactions keep failing

$ cd example/zrc2
$ node transfer.js 
Your account address is:
0x501A70ffEAA3F31C1caccE3479e74713546BAA44
undefined

Why this undefined?

If I add console.log(JSON.stringify(callTx, null, 4)); after await contract.call(...), I get:

{
    "code": "",
    "data": "{\"_tag\":\"Transfer\",\"params\":[{\"vname\":\"to\",\"type\":\"ByStr20\",\"value\":\"0xBFe2445408C51CD8Ee6727541195b02c891109ee\"},{\"vname\":\"amount\",\"type\":\"Uint128\",\"value\":\"100\"}]}",
    "version": 21823489,
    "toAddr": "0x509aE6e5D91CEE3c6571Dcd04aa08288a29D563A",
    "nonce": 130,
    "pubKey": "03043f88a66a8d79df51c17b7297239b613db510abb04dddc072f0aac5666e716e",
    "amount": "0",
    "signature": "8dc1069bf5b4473ca255f393f026b10c55b705d8fd1859a4149983b4686d078866499a9a43e66df038d2defb35328a1f5eba5da97ac3908fa093ff83c5f50460",
    "gasPrice": "3b9aca00",
    "gasLimit": {
        "low": 10000,
        "high": 0,
        "unsigned": false
    },
    "provider": {
        "middleware": {
            "request": {},
            "response": {}
        },
        "nodeURL": "https://dev-api.zilliqa.com",
        "reqMiddleware": {},
        "resMiddleware": {}
    },
    "status": 3,
    "toDS": false,
    "blockConfirmation": 0,
    "eventEmitter": {
        "handlers": {},
        "emitter": {},
        "promise": {}
    }
}

Does "status": 3 mean "Consensus failure in network"? What is it? Why? How to make it work?

Inconsistent behaviors of procedures in ZRC1

There are inconsistent behaviors of some procedures in ZRC1.
e.g.

  • 🟢 IsTokenOwner throws an error if not a token owner
  • 🟢 IsMinter throws an error if not a minter
  • 🔴 IsSelf throws an error if self
  • 🔴 IsTokenExists throws an error if the token exists

This inconsistency can be confusing and error-prone.

Therefore the following can be

  • 🔴 IsSelf throws an error if self
  • 🔴 IsTokenExists throws an error if the token exists

changed to

  • 🟢 IsNotSelf throws an error if self
  • 🟢 IsTokenNotFound throws an error if the token exists

ZRC#2: dummy ADT

Lines 39-41 in the ZRC-2 reference contract (fungible token) look like they should be removed , see

(* Dummy user-defined ADT *)

(* Dummy user-defined ADT *)
type Unit =
| Unit

This ADT Unit is not used anywhere.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.