Releases: ecadlabs/taquito
10.2.0-beta-RC.0
Summary
New features
- @taquito/contract-library - [Performance] Embed popular contracts into your application using the new ContractAbstraction instantiation #1049
- @taquito/rpc - [Performance] Enable RPC caching in your application using the RpcClient cache implementation #924
- @taquito/taquito - [DevExp] Taquito Entrypoint methods now accept javascript object format for contract method calls (parametric calls are unchanged!) #915
Enhancements
- Compatibility support for Hangzhounet
- Allow to set HttpBackend on IpfsHttpHandler #1092
@taquito/contract-library - Ability to bundle smart-contract scripts and entrypoints for ContractAbstration instantiation
A new package named @taquito/contract-library has been added to the Taquito library.
To improve (d)App performance, we aim to provide ways to reduce the number of calls made by Taquito to the RPC. The @taquito/contracts-library package allows developers to embed the smart-contract scripts into the application, preventing Taquito from loading this data from the RPC for every user.
The ContractsLibrary class is populated by at project compile time, using contract addresses and their corresponding script and entry points. The ContractsLibrary is then injected into a TezosToolkit as an extension using the toolkits addExtension method.
When creating a ContractAbstraction instance using the at method of the Contract or the Wallet API, if a ContractsLibrary is present on the TezosToolkit instance, the script and entry points of matching contracts will be loaded from the ContractsLibrary. Otherwise, the values will be fetched from the RPC as usual.
Example of use:
import { ContractsLibrary } from '@taquito/contracts-library';
import { TezosToolkit } from '@taquito/taquito';
const contractsLibrary = new ContractsLibrary();
const Tezos = new TezosToolkit('rpc');
contractsLibrary.addContract({
'contractAddress1': {
script: script1, // script should be obtained from Tezos.rpc.getScript('contractAddress1')
entrypoints: entrypoints1 // entrypoints should be obtained from Tezos.rpc.getEntrypoints('contractAddress1')
},
'contractAddress2': {
script: script2,
entrypoints: entrypoints2
},
//...
})
Tezos.addExtension(contractsLibrary);
// The script and entrypoints are loaded from the contractsLibrary instead of the RPC
const contract = await Tezos.contract.at('contractAddress1');@taquito/RPC - New RpcClient implementation that caches RPC data
Similar to the new ContractsLibrary feature, Taquito provides an additional way to increase dApp performance by caching some RPC data. To do so, we offer a new RpcClient implementation named RpcClientCache
The constructor of the RpcClientCache class takes an RpcClient instance as a parameter and an optional TTL (time to live). By default, the TTL is of 1000 milliseconds. The RpcClientCache acts as a decorator over the RpcClient instance. The RpcClient responses are cached for the period defined by the TTL.
Example of use:
import { TezosToolkit } from '@taquito/taquito';
import { RpcClient, RpcClientCache } from '@taquito/rpc';
const rpcClient = new RpcClient('replace_with_RPC_URL');
const tezos = new TezosToolkit(new RpcClientCache(rpcClient));@taquito/taquito - New Taquito Entrypoint methods accept javascript object format for contract method calls
The ContractAbstraction class has a new member called methodsObject, which serves the same purpose as the methods member. The format expected by the smart contract method differs: methods expects flattened arguments while methodsObject expects an object.
It is to the user's discretion to use their preferred representation. We wanted to provide Taquito users with a way to pass an object when calling a contract entry point using a format similar to the storage parameter used when deploying a contract.
A comparison between both methods is available here: https://tezostaquito.io/docs/smartcontracts#choosing-between-the-methods-or-methodsobject-members-to-interact-with-smart-contracts
Compatibility support for Hangzhounet
This version ships with basic compatibility support for the new Hangzhou protocol. New features, such as support for new Michelson instructions, types and constants, will follow in future Taquito releases.
What's coming next for Taquito?
We started preliminary work on integrating Hangzhounet, the next Tezos protocol update proposal. We plan to deliver a final version of Taquito v11 early, giving teams a longer runway to upgrade their projects before protocol transition.
If you have feature or issue requests, please create an issue on http://github.com/ecadlabs/taquito/issues or join us on the Taquito community support channel on Telegram https://t.me/tezostaquito
Taquito v10.1.3-beta
Bug fix - Key ordering
Fixed key sorting in literal sets and maps when these collections have mixed key types.
Upgrade beacon-sdk to version 2.3.3
This beacon-sdk release includes:
- updated Kukai logo
- hangzhounet support
- fix for #269 Pairing with Kukai blocked (from -beta.0)
Taquito v10.1.2-beta
Taquito v10.1.1-beta
Bugfix where the custom polling interval values for the confirmation methods were overridden with the default ones.
10.1.0-beta
Taquito v10.1.0-beta
Breaking change
In version 9.2.0-beta of Taquito, the ability to send more than one operation in the same block was added to Taquito. This ability relied on a workaround solution. The helpers/preapply/operations and helpers/scripts/run_operation RPC methods do not accept a counter higher than the head counter + 1 as described in issue tezos/tezos#376. Despite the limitation of these RPC's, the Tezos protocol itself does allow the inclusion of more than one operation from the same implicit account. In version 9.2.0-beta of Taquito, we introduced an internal counter and simulated the operation using a counter value that the preapply & run_operation will accept. This allowed Taquito to send many operations in a single block. However, we found that the workaround used may lead to inconsistent states, and results that violate the principle of least astonishment. We decided to remove this feature temporarily. We aim to reintroduce this feature when Tezos RPC issue tezos/tezos#376 is addressed and considers the transaction in the mempool when checking the account counter value or otherwise by providing a separate and adapted new interface to support this use case properly.
Summary
Enhancements
- @taquito/taquito - Made PollingSubscribeProvider's polling interval configurable #943
- @taquito/taquito - Possibility to withdraw delegate
Bug Fixes
- @taquito/taquito - Added a status method for batched transactions using the wallet API #962
- @taquito/michelson-encoder - Fixed the Schema.ExecuteOnBigMapValue() for ticket token #970
- @taquito/taquito - Fixed a "Memory leak" in the PollingSubscribeProvider #963
Documentation
- Updated Taquito website live examples to use Granadanet #993
- Documentation for FA2 functionality #715
- Documentation for confirmation event stream for wallet API #159
@taquito/taquito - Made PollingSubscribeProvider's polling interval configurable
The default streamer set on the TezosToolkit used a hardcoded polling interval of 20 seconds, and there was no easy way to change this. To reduce the probability of missing blocks, it is now possible to configure the interval as follow:
const tezos = new TezosToolkit('https://api.tez.ie/rpc/mainnet')
tezos.setProvider({ config: { streamerPollingIntervalMilliseconds: 15000 } });
const sub = tezos.stream.subscribeOperation(filter)@taquito/taquito - Possibility to withdraw delegate
It is now possible to undelegate by executing a new setDelegate operation and not specifying the delegate property.
// const Tezos = new TezosToolkit('https://YOUR_PREFERRED_RPC_URL');
await Tezos.contract.setDelegate({ source: 'tz1_source'});@taquito/taquito - Property status doesn't exist on a batched transaction for the wallet API
When multiple operations were batched together using the batch method of the wallet API, the send() method returned a value of type WalletOperation where the status was missing. BatchWalletOperation, which extends the WalletOperation class and contains a status method, is now returned.
@taquito/michelson-encoder - Fixed the Schema.ExecuteOnBigMapValue() for ticket token
The Execute and ExecuteOnBigMapValue methods of the Schema class could not deserialize Michelson when ticket values were not in the optimized (Edo) notation. Both representations are now supported.
@taquito/taquito - Fixed a "Memory leak" in the PollingSubscribeProvider
A fix has been made to change the behavior of the PollingSubscribeProvider, which was keeping all blocks in memory.
10.1.0-beta-RC.0
Taquito v10.1.0-beta
Breaking change
In version 9.2.0-beta, the possibility to send more than one operation in the same block has been introduced to Taquito. It was a workaround solution as the helpers/preapply/operations and helpers/scripts/run_operation APIs of the RPC do not accept a counter higher than the head counter + 1 as described in this issue. Still, the node allows the injection of simultaneous operation. In version 9.2.0-beta of Taquito, we introduced an internal counter and simulated the operation using the RPC expected counter to send many operations in a row. However, the hacked simulation may lead to inconsistent states, making it impossible to provide the same user experience. We decided to disable this feature temporarily. We apologize for the inconvenience brought by this decision. We aim to reintroduce this feature if the RPC API considers the transaction in the mempool when checking the account counter value or otherwise by providing a separate and adapted new interface to support this use case properly.
Summary
Enhancements
- @taquito/taquito - Made PollingSubscribeProvider's polling interval configurable #943
- @taquito/taquito - Possibility to withdraw delegate
Bug Fixes
- @taquito/taquito - Added a status method for batched transaction using the wallet API #962
- @taquito/michelson-encoder - Fixed the Schema.ExecuteOnBigMapValue() for ticket token #970
- @taquito/taquito - Fixed a "Memory leak" in the PollingSubscribeProvider #963
Documentation
- Updated Taquito website live examples to use Granadanet #993
- Documentation for FA2 functionality #715
- Documentation for confirmation event stream for wallet API #159
Taquito v10.0.0-beta
Summary
Remaining support for Granadanet
- @taquito/rpc - Support
depositsfield infrozen_balance#919 - @taquito/rpc - Support new fields introduced by Granada in block metadata #918
Bug Fixes
- @taquito/taquito - Drain an unrevealed account #975
- @taquito/rpc - Type
ContractBigMapDiffItemhas BigNumber's but values are string's #946
Documentation
- Document usage of Taquito with TezosDomain #912
- Document storage and fee passing from wallet to dapp #926
- Add integration tests for Permit contracts (TZIP-17) #661
Enhancements
- Breaking changes - @taquito/michelson-encoder - Improvement to the
Schema.ExtractSchema()method #960 and #933
@taquito/rpc - Support deposits field in frozen_balance
In Granada, when fetching delegate information from the RPC, the deposit property in frozen_balance_by_cycle has been replaced by deposits. The RpcClient supports the new and the old notation.
@taquito/rpc - Support new fields introduced by Granada in block metadata
The balance_updates property in block metadata now includes the new origin subsidy, besides the existing ones: block and migration.
The support for the new liquidity_baking_escape_ema and implicit_operations_results properties in block metadata has been added in the RpcClient class.
@taquito/taquito - Drain an unrevealed account
Since v9.1.0-beta, the fees associated with a reveal operation are estimated using the RPC instead of using the old 1420 default value. When draining an unrevealed account, the fees associated with the reveal operation needs to be subtracted from the initial balance (as well as the fees related to the actual transaction operation). The reveal fee has changed from 1420 to 374 (based on the simulation using the RPC). However, the constants file was still using the 1420 value, leading to a remaining amount of 1046 in the account when trying to empty it. The default value has been adjusted on the constants file to match this change.
@taquito/rpc - Type ContractBigMapDiffItem has BigNumber's but values are string's
The type of the big_map, source_big_map, and destination_big_map properties of ContractBigMapDiffItem was set as BigNumber, but they were not cast to it. The RPC returns these properties in a string format. The type has been changed from BigNumber to string for them.
Add integration tests for Permit contracts (TZIP-17)
Examples have been added to the integration tests showing how to manipulate permit contracts using the new data packing feature: https://github.com/ecadlabs/taquito/blob/master/integration-tests/contract-permits.spec.ts
@taquito/michelson-encoder - Improvement to the Schema.ExtractSchema() method
TheExtractSchema method of the Schema class indicates how to structure contract storage in javascript given its storage type in Michelson JSON representation. This method can be helpful to find out how the storage object needs to be written when deploying a contract.
Return the type of element(s) that compose a "list"
Before version 10.0.0-beta, when calling the Schema.ExtractSchema method, the Michelson type list was represented only by the keyword list. This behavior has been changed to return an object where the key is list and the value indicates the list's composition.
Example:
const storageType = {
prim: 'list',
args: [
{
prim: 'pair',
args: [
{ prim: 'address', annots: ['%from'] },
{ prim: 'address', annots: ['%to'] },
],
},
],
};
const storageSchema = new Schema(storageType);
const extractSchema = storageSchema.ExtractSchema();
println(JSON.stringify(extractSchema, null, 2));
before version 10.0.0-beta, the returned value was:
'list'
in version 10.0.0-beta the returned value is:
{
list: {
"from": "address",
"to": "address"
}
}
Based on the information returned by the ExtractSchema method, the storage can be writen as follow:
Tezos.contract
.originate({
code: contractCode,
storage: [
{
from: "tz1...",
to: "tz1..."
}
],
})
Breaking changes - Change in the representation of big_map type
The representation of the big_map type returned by the Schema.ExtractSchema method has changed to increase consistency with the map representation. Similar to the map type, an object is now returned where its key is big_map, and its value is another object having a key and a value property, indicating the type of the key and value of the big map. At the same time, this change fixed an issue where the key of a big map as pair was not represented properly and returned "[object Object]" instead.
Example:
const storageType = {
prim: 'big_map',
annots: [ '%balances' ],
args: [
{
prim: 'address'
},
{
prim: 'pair',
args: [ { prim: 'address' }, { prim: 'nat' } ]
}
]
};
const storageSchema = new Schema(storageType);
const extractSchema = storageSchema.ExtractSchema();
println(JSON.stringify(extractSchema, null, 2));
before version 10.0.0-beta the returned value was:
{
"address": {
"0": "address",
"1": "nat"
}
}
in version 10.0.0-beta the returned value is:
{
"big_map": {
"key": "address",
"value": {
"0": "address",
"1": "nat"
}
}
}
Based on the information returned by the ExtractSchema method, the storage can be writen as follow:
const bigMap = new MichelsonMap();
bigMap.set('tz1...', { // address
0: 'tz1...', // address
1:10 // nat
});
Tezos.contract
.originate({
code: contractCode,
storage: bigMap
})
What's coming next for Taquito?
Taquito team is committed to creating the best experience for Taquito users, and we need your feedback!
Please help us improve Taquito further by filling out this 2-minute survey by EOD August 1 (PST).
https://forms.gle/mqYySKeaWUUkF5NXA
Thank you for your time and support!
If you have feature or issue requests, please create an issue on http://github.com/ecadlabs/taquito/issues or join us on the Taquito community support channel on Telegram https://t.me/tezostaquito
Taquito v9.2.0-beta
Summary
New features
- Compatibility support for Granadanet
- @taquito/michelson-encoder - Accept bytes in Uint8Array #375
- @taquito/michelson-encoder - Added Bls12-381 tokens #888
- @taquito/michelson-encoder - Added sapling_state and sapling_transaction tokens #586
- @taquito/rpc - Added sapling RPC #586
- @taquito/taquito - sapling_state abstraction on storage read #602
- @taquito/taquito - Possibility to send more than one operation in the same block #955
Documentation
- @taquito/http-utils - Cancel http requests
Enhancements
- Updated various dependencies and switched from tslint to eslint
@taquito/michelson-encoder - Accept bytes in Uint8Array
The only format accepted in the Michelson-encoder for the type bytes was the hexadecimal string. We added support for the type Uint8Array. It is now possible to call an entry point or originate a contract using a Uint8Array or a hexadecimal string.
@taquito/http-utils - Make http requests cancelable
We received requests from users to use the abort signal to allow making requests cancelable. This implementation would require changes in the high-level API that we will consider in an incoming issue where we envisage providing a new API. Meanwhile, it is possible to customize the HttpBackend and RpcClient classes to support cancelable requests. Here is an example where a custom HttpBackend class is used to be able to cancel all requests: https://tezostaquito.io/docs/cancel_http_requests
The example, as not specific, might not be ideal for all use cases, so we plan to provide better support for this feature in the future.
@taquito/michelson-encoder - Added Bls12-381 tokens
The bls12_381_fr, bls12_381_g1, and bls12_381_g2 tokens were missing in the Michelson-Encoder since the Edo protocol and have been added. As for the bytes token, their supported format is the hexadecimal string or the Uint8Array.
@taquito/michelson-encoder - Added sapling_state and sapling_transaction tokens
The sapling_state and sapling_transaction tokens were missing in the Michelson-Encoder since the Edo protocol and have been added.
Note that no additional abstractions or ability to decrypt Sapling transactions have been implemented so far.
@taquito/rpc - Added sapling RPC
The RPC endpoints related to sapling have been added to the RpcClient:
- the
getSaplingDiffByIdmethod takes a sapling state ID as a parameter and returns its associated values. - the
getSaplingDiffByContracttakes the address of a contract as a parameter and returns its sapling state.
@taquito/taquito - sapling_state abstraction on storage read
When accessing a sapling_state in the storage with the RPC, only the sapling state's ID is returned.
When fetching the storage of a contract containing a sapling_state, Taquito will provide an instance of SaplingStateAbstraction. The SaplingStateAbstraction class has a getId and a getSaplingDiff methods.
The getSaplingDiff method returns an object of the following type:
{
root: SaplingTransactionCommitmentHash,
commitments_and_ciphertexts: CommitmentsAndCiphertexts[];
nullifiers: string[];
}
@taquito/taquito - Possibility to send several operations in the same block
Unless using the batch API, a specific account was limited to only sending one operation per block. If trying to send a second operation without awaiting confirmation on the first one, a counter exception was thrown by the RPC.
The node accepts the injection of more than one operation from the same account in the same block; the counter needs to be incremented by one for each of them. A limitation comes from the chains/main/blocks/head/helpers/scripts/run_operation and /chains/main/blocks/head/helpers/preapply/operations RPC APIs as they do not take into account the transaction in the mempool when checking the account counter value.
We added a counter property (a map of an account and its counter) on the TezosToolkit instance as a workaround. The counter is incremented when sending more than one operation in a row and used to inject the operation. However, the counter used in the prevalidation or the estimation is the head counter + 1. Note that if you send multiple operations in a block to a contract, the estimate will not take into account the impact of the previous operation on the storage of the contract. Consider using the batch API to send many operations at the same time. The solution presented in this issue is a workaround; the operations will need to be sent from the same TezosToolkit instance as it will hold the counter state.
What's coming next for Taquito?
We will work on integrating flextesa node into our CI pipeline. We are currently relying on testnets for testing purposes. Since many Taquito users use flextesa for testing, including it in our development process will help provide better support, especially regarding errors encountered during Operation.confirmation() issues.
We plan to improve performance issues by implementing some caching. Please have a look at these open discussions: #917 #916. Any feedback or suggestions are appreciated.
If you have feature or issue requests, please create an issue on http://github.com/ecadlabs/taquito/issues or join us on the Taquito community support channel on Telegram https://t.me/tezostaquito
Taquito v9.1.1-beta
@taquito/beacon-wallet - Updated beacon-sdk to version 2.2.9
@taquito/michelson-encoder - Fix for unexpected MapTypecheckError when loading contract storage - for cases where a map contains a big map as value #925
9.1.1-beta-RC.0
- @taquito/beacon-wallet - Updated beacon-sdk to version 2.2.9-beta.3
- @taquito/michelson-encoder - Fix for unexpected MapTypecheckError when loading contract storage - for cases where a map contains a big map as value #925