ecadlabs / taquito Goto Github PK

As a developer

I want to be able to query the monitor block endpoint

In order to see last update to the Tezos network and update my application

As a developer

I want to be able to query contract storage history

Use case:
Produce a graph of account balances for a fungible asset token over-time.

Being able to query smart contract storage and see changes over time
This would include storage and big map storage query

Add support for the endorsing right support in @tezos-ts/rpc package

https://tezos.gitlab.io/mainnet/api/rpc.html#get-block-id-helpers-endorsing-rights

Add a confirmation event stream on operations.

This will allow developers to subscribe to events such as confirmations, making it easier to implement better UX.

A common use case for this would be to show progress of a transaction

Via the telegram tezos developers channel, a couple people asked that we publish packages to a CDN so that they can include the library using a <script...> tag on their web page/app.

We can use https://www.jsdelivr.com for this.

Using the <script> tag is not ideal, as the developer misses out on tree shaking and other nice ot have features, but to each their own.

We will likely make an all in one minified file including all lower-level packages. The asset size will be a bit larger, but it will be simpler. If developers are concerned about size, they should probably switch to a bundler and define dependencies in package.json

I'm having the following error using the Tezos.contract.transfer method.

{
  status: 500,
  statusText: 'Internal Server Error',
  body: '[{"kind":"branch","id":"proto.005-PsBABY5H.contract.previously_revealed_key","contract":"tz1bwT9XB9tpzTKKw7UtTSzS9dfXjAzqXzoi"}]\n'
}

My server is a local zeronet node and I'm running this script:

const { Tezos } = require('@taquito/taquito')
const { InMemorySigner } = require('@taquito/signer')
..
const privateKey = 'edsk4KYzU19Hj7wuZX9it5L6pyRwz9zss2wk627kkvuGJB7vXHcwB8'
const server = 'http://127.0.0.1:8732'
Tezos.setProvider({signer: new InMemorySigner(privateKey)})
Tezos.setProvider({rpc: server})
const some_address = 'tz1bwT9XB9tpzTKKw7UtTSzS9dfXjAzqXzoi'
Tezos.contract.transfer({to: contract_address, amount: 2}).then (
    x => console.log(x)
).catch(
    x => console.log(x)
)

I have no issue running the same transaction with tezos-client. Am I doing anything wrong?

Add Interface and an RPC implementation for getting constants.

RPC API docs;
https://tezos.gitlab.io/tezos/api/rpc.html#get-block-id-context-constants

Example curl command;
curl http://10.60.58.16:8732/chains/main/blocks/5/context/constants
curl http://10.60.58.16:8732/chains/main/blocks/head/context/constants

• Implement interface
• Implement default rpc implementation for interface
• Implement type to represent constants
• Add call to examples/

Tentative description for API doc;

getConstants returns the economic constants for the given chain. Constants are constant in the context of a block. Constants were initialized in the genesis block and can only be changed by a Tezos protocol amendment. Constants are or can be different on mainnet, alphanet or other nets.

@tezos-ts/michelson-encoder should decode int, nat and mutez token to BigNumber

Add support for the backing right support in @tezos-ts/rpc package

https://tezos.gitlab.io/mainnet/api/rpc.html#get-block-id-helpers-baking-rights

It has been suggested that we could allow cancellation of operation in the mempool before the operation gets included a block.

Example of the suggestion:

const promise = Tezos.contract.originate({ ...payload}, cancellationToken)
cancellationToken.cancel()
const op = await promise
assert(op.cancelled === true)

We have created a couple React components for developers to use directly or to use as reference.

Let's evaluate building web components using stenciljs.com and see if the react/ember/angular/vue.js components that stencil produces are decent. The main risk I'm concerned about is that the resulting components become poor implementations. The upside or proposition of stenciljs is very compelling. Hence this is worth exploring.

Provide tz and mtz format to the Balance components

RPC calls do not support Michelson macro's.

We would like to be able to expand macros while building the smart contract origination operation

See: https://tezos.gitlab.io/whitedoc/michelson.html#macros

The idea would be something like combining storage limit and fees.

Instead of having to set them in 2 separate fields, we could have one burn-cap property that makes sure the total spent is less than what the user-specified.

As a developer

I want to get baking information of a delegate

The RPC endpoint to implement support for is http://tezos.gitlab.io/mainnet/api/rpc.html#get-block-id-context-delegates-pkh

Properties needs to be camel case and we need to ensure that all balances are bigNumber

We want to mock HttpRequest for our tests. So lets add an optional constructor argument - "creator" function. If it's defined then createXHR method returns its result.

Guidelines for writing unit tests.

For unit tests that uses static input that came from the chain, it will be useful to the reader to name the data (or variable containing the data) with the protocol of the data from which it originated.

Data shape may change over time with new upgrades, so making this information explicit should make it easier for our future selves to see what is under test.

Context/impetus: #22 (comment)

Draft for new "Unit-tests guidelines" documentation.

When writing tests for a function that takes sample data, the unit-test author should illustrate the origin of the input data. For example, if the developer is writing a unit-test for a hypothetical method is named parseOperation(), the unit-test should make clear what protocol the test fixture data is originating from.

For example:

• parseOperation(op_005) where the operation test fixture is congruent with an operation from the Babylon/005 protocol
• parseOperation(op_006) where the operation test fixture is congruent with an operation from the Carthage/006 protocol

Tagging unit tests that operate on functions

For code that deals with data that may change based on what protocol is being tested, the unit-test should be marked (Note, How should we mark these tests??) so that when we add new protocol support to Taquito, we can get a list of all unit-tests that require to have additional test-fixtures added for the upcoming protocol

As a developer

I want to get a specific block using the Tezos RPC (http://tezos.gitlab.io/mainnet/api/rpc.html#get-block-id)

import RpcClient from '@tezos-ts/rpc';

const client = new RpcClient();

const block = await client.getBlock('head');

Add support for each of these endpoint in the @tezos-ts/rpc package

• https://tezos.gitlab.io/mainnet/api/rpc.html#get-block-id-votes-ballot-list
• https://tezos.gitlab.io/mainnet/api/rpc.html#get-block-id-votes-ballots
• https://tezos.gitlab.io/mainnet/api/rpc.html#get-block-id-votes-current-period-kind
• https://tezos.gitlab.io/mainnet/api/rpc.html#get-block-id-votes-current-proposal
• https://tezos.gitlab.io/mainnet/api/rpc.html#get-block-id-votes-current-quorum
• https://tezos.gitlab.io/mainnet/api/rpc.html#get-block-id-votes-listings
• https://tezos.gitlab.io/mainnet/api/rpc.html#get-block-id-votes-proposals

Validate hashes that have checksums and avoid making HTTP calls when we can determine that the parameters are invalid.

Addresses, block hashes, and so forth have a checksum. We intend to add support to validate locally. (We are currently deferring such validation to the node.) By supporting this validation within the library, we can give end-users and developers a better experience by detecting problems or input errors earlier.

Acceptance criteria:

• Implement a validation function that checks:
  • [x ] Addresses (Link to utility method here)' - Already DONE
  • [x ] Chain - Already DONE
  • Operation Hash
  • Block Hash
  • Protocol Hash
  • ??? Do we need any other items to be added here?

ToDo:

• List all hashes that can be validated.
• Make sure each one has a method (add to the list below)
• Make sure each one has documentation

See: https://tezostaquito.io/docs/validators

We support parameter encoding when we call smart contracts, but we still need to add storage encoding when we originate smart contract

{
    "prim": "Pair",
    "args": [
        {
            "prim": "Pair",
            "args": [
                {
                    "prim": "Pair",
                    "args": [
                        {
                            "int": "123"
                        },
                        {
                            "string": "tz1RvhdZ5pcjD19vCCK9PgZpnmErTba3dsBs"
                        }
                    ]
                },
                {
                    "prim": "Pair",
                    "args": [
                        {
                            "prim": "Pair",
                            "args": [
                                {
                                    "int": "123"
                                },
                                {
                                    "int": "123"
                                }
                            ]
                        },
                        {
                            "prim": "Pair",
                            "args": [
                                [
                                    {
                                        "prim": "Pair",
                                        "args": [
                                            {
                                                "string": "2017-08-14T18:00:21Z"
                                            },
                                            {
                                                "int": "123"
                                            }
                                        ]
                                    }
                                ],
                                [
                                    {
                                        "prim": "Pair",
                                        "args": [
                                            {
                                                "string": "2017-08-14T18:00:21Z"
                                            },
                                            {
                                                "int": "123"
                                            }
                                        ]
                                    }
                                ]
                            ]
                        }
                    ]
                }
            ]
        },
        {
            "prim": "Pair",
            "args": [
                {
                    "string": "tz1RvhdZ5pcjD19vCCK9PgZpnmErTba3dsBs"
                },
                {
                    "int": "123"
                }
            ]
        }
    ]
}

Instead we could use an object that maps the schema

{
    "0": "123",
    "1": "tz1RvhdZ5pcjD19vCCK9PgZpnmErTba3dsBs",
    "2": "0.000123",
    "3": "123",
    "4": [
        [
            "14/08/2017, 18:00:21",
            "0.000123"
        ],
        [
            "14/08/2017, 18:00:21",
            "0.000123"
        ]
    ],
    "6": "tz1RvhdZ5pcjD19vCCK9PgZpnmErTba3dsBs",
    "7": "123"
}

We plan to use SemVer style versions for tezos-ts but we will make the major version number track the version number of the supported economic protocol.

This would make our first version number v4.0.0 as it would support 004-Pt24m4xi
The next major version number (assuming Babylon is accepted) could be v5.0.0 which would correspond with 005-PsBABY5n

Outline;

• Need for clear version numbers
• Tension between SemVer and bumping major number even when API surface may not have big changes. (read, not SemVer but SemVer style).
• alpha releases for new protos when proposal passes proposal phase
• beta as soon as is responsible
• final released prior to protocol transitioning to new protocol version.
• All clients must be backward compatible with historic blocks all the way to genesis.
• Support policy for versions will be current proto and proto+1.
• Proto+1 releases should always be released a couple weeks prior to transition

As a developer

I want to have a signing provider that is easily overridable

In order to sign various operations and block on behalf of my user before I submit them to Tezos Network.

import Signer from '@tezos-ts/signer'

const data = <hex_data>

const tezosEncodedSignature = await signer.sign(data);

The general idea is to provide a base implementation that can read private keys and do local signing of operations. Once we have that we can provide other implementation to support remote signers or wallets

We consider the current implementation of the Michelson parser is a prototype. The current implementation is naïve and doesn't deal with some known edge cases and probably many more unknown edge-cases. (We don't know what we don't know 🤪).

Work is underway by the Nomadic team to produce a JS/Wasm build of the OCaml Michelson encoder, which is the defacto package. When that is ready, we will switch our implementation to depend on that package moving forward

See: https://gitlab.com/tezos/tezos/issues/581

Using a toolkit that can rely on Typescript or Javascript, create a template app that builds a simple mobile app for iOS & Android that uses Taquito to perform basic interactions (reading and writing) with the Tezos blockchain.

The goal is to give new developers a running start at implementing their new idea for a Mobile app that interacts with the Tezos blockchain.

Platforms of interest are;

• Swift (iOS)
• Flutter
• Kotlin or Java (Android)
• Cordova

As a developer

I want to be able to forge operations using the http://tezos.gitlab.io/mainnet/api/rpc.html#post-block-id-helpers-forge-operations endpoint

import RpcClient from '@tezos-ts/rpc';

const client = new RpcClient();

const operation = {
  "branch": "BMHBtAaUv59LipV1czwZ5iQkxEktPJDE7A9sYXPkPeRzbBasNY8",
  "contents": [
    { "kind": "transaction",
      "source": "tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx",
      "fee": "50000",
      "counter": "3",
      "gas_limit": "200",
      "storage_limit": "0",
      "amount": "100000000",
      "destination": "tz1gjaF81ZRRvdzjobyfVNsAeSC6PScjfQwN"
   } ]
}

const forgedOperation = await client.forgeOperations(operation);

There is multiple kind of different operation and knowing what format they have can be tricky for newcomers. It will be useful to have some utility function that are properly typed in order to create them.

Implement ReasonML bindings for Taquito to make Taquito pleasent to use with ReasonML.

There is already a few smart contract file in the Tezos GitLab repo. We could leverage these to test our origination logic.

Also, there are some interesting scenario that we could implement in typescript:

https://gitlab.com/tezos/tezos/-/tree/master/tests_python/tests

As a developer

I want to be able to inject operation into a Tezos node using the RPC endpoint (http://tezos.gitlab.io/mainnet/api/rpc.html#post-injection-operation)

import RpcClient from '@tezos-ts/rpc';

const client = new RpcClient();

const op = '<hex_encoded_operation>';

const result = await client.injectOperation(op);

The bus factor at ECAD is 4+, we have at least 4 staff that are capable of maintaining Taquito.

We would like to improve the bus factor on an organizational scale. Suppose that ECAD, hypothetically turned anti-opensource and erected barriers and commercial on-ramps for using Taquito. By having more organizations and individual developers outside of ECAD is healthy for the project and reduced risk to others.

Ideas to improve bus-factor;

• Make the project friendly to new contributors
• Encourage other ecosystem teams to make PR's
• Consider doing a work-exchange program where ECAD and another team will exchange an engineer for a fixed period where the ECAD member will work on the other team's project of choice, and the other engineer gets to work full time on Taquito.

The envoy governance document could serve as a useful model https://github.com/envoyproxy/envoy/blob/master/GOVERNANCE.md

As a developer

I want to query an address balance history

As of v5.1.0, Taquito supports the forging of operations by calling the RPC forge method. We wish to support local forging, so developers do not need to rely on a remote node, due to the associated security and performance implications.

Adding an opt-in package @taquito/forge could provide flexibility to our users.

Right now users have to guess required gas for their operation.

We would like to provide functionality to approximate the correct parameter when they send a transaction.

Test more operation variants for the getBlock endpoint in @taquito/rpc

• add tests based on data from proto 5, 6 and 7
• test other operations (transaction, origination, ...)

see comment #35 (comment)

Set up circle CI to;

• Run lint
• Run tests
• Add circle ci build badge to README

Process outside of CI (releases)

• Generate packages.
• Push packages to npm

Bonus items;

• Publish web components to public gallery

Add an easy way to get the origination burn amount through the OriginationOperation.

This can also be applied to other operation kind.

As a developer I want to get a "subscribe" to the balance of an address so that I can display the balance of an address that updates in near real-time on my web app

At the moment, we are mostly doing unit tests against each part of tezos-ts. We want a way to test the library functionalities against real nodes and in an automated way.

Ideally, we would only use the public API of our packages to implement those tests.

• Add a new e2e tests project that will depend on each package and only use the public API to do the tests
• Add job on CI to run this new tests suite (trigger should be on PR or tags)

As of v5.1.0 Taquito's errors are not well defined and are inconsistent.

• We must define a strategy for our error schema and make them part of our API.
  For instance, some error from the RPC are just plain object and other packages returns an Error instance. By applying a consistent approach to errors, the developer experience will improve.
• Double check if errors are informative and actionable
• Create follow-up issues based on the design.

Currently, we need to set taquito providers using the setProvider method.

Even if the setProvider exposes an easy to change multiple providers at a time some users might appreciate to be able to change one provider using a specific method. For instance:

Instead of doing Tezos.setProvider({signer: mySigner})

We could add method to do:
Tezos.setSigner(mySigner)

Proposed api

const tzAmount = Tezos.from('mtz', 'tz', mtzAmount)

Allow users to do a dry run of their operation before sending it

Interfaces and default(rpc) implementation for:

• getBalance
• getStorage
• getScript
• getContract
• getManager
• getDelegate
• getBigMapKey -

getStorage should parse the RPC data into a more dev friendly js object.

We can define a future block height that we anticipate (but not assume) the protocol version will change. This MAX_COMPAT_BLOCK_HEIGHT constant can be compared to the current height of a block.

If current block that the library deals with is greater than MAX_COMPAT_BLOCK_HEIGHT then emit a soft warning log message;
The version of your tezos-ts suite of packages is likely out of date, and may not operate with blocks greater than ${MAX_COMPAT_BLOCK_HEIGHT}. Please consider updating your tezos-ts packages to avoid unexpected behavior.

A risk arises if we forget to update MAX_COMPAT_BLOCK_HEIGHT. Maybe doing a check on this during ci test phase would be prudent.

The current implementation of importKey only support private key. We would like it to also support import faucet account.

Faucet account require an activation operation to be published to be used and their secret key can be retrieved using the in memory signer factory function.

We would like to abstract this process in the importKey method

// An account can already be activated in such case we should just ignore this step
const activationOperation = Tezos.tz.activate(pkh, secret)
await activationOperation.confirmation()

const signer = InMemorySigner.fromFundraiser(email,password, mnemonic)
Tezos.setProvider({signer})

The proposed API would be:

Tezos.importKey(email, passphrase, mnemonic)

Goal: to create a web form demo with the goal of improving Taquito APIs.

Story 1 contract methods

As a developer user of Taquito, I want to easily generate a web-form based on arbitrary smart contract methods so that I can quickly build applications with forms that correspond to the contract.

Story 2 initial storage

As a developer user of Taquito, I want to generate a web form for the storage type of my Michelson contract so that I can easily and conveniently generate a user interface that allows me to define the initial storage values for a smart contract that I am about to originate.

Right now users need to access newly originated contract by inspecting the origination result.

op.results[0].metadata.operation_result.originated_contracts[0]

We would like to provide convenient access to the newly created contract.

• A property on the operation for the originated address. op.contractAddress
• A property on the operation for accessing contract abstraction. await op.contract()