hyperledger / iroha-javascript Goto Github PK
View Code? Open in Web Editor NEWJavaScript library for Iroha, a Distributed Ledger Technology (blockchain) platform.
Home Page: https://wiki.hyperledger.org/display/iroha
License: Apache License 2.0
JavaScript library for Iroha, a Distributed Ledger Technology (blockchain) platform.
Home Page: https://wiki.hyperledger.org/display/iroha
License: Apache License 2.0
This code fails in Vite:
import { init } from '@iroha2/crypto-target-web'
await init()
https://github.com/0x009922/iroha-js-sdk-issue-104-repro
It includes error details.
Using ?url
suffix:
import { init } from '@iroha2/crypto-target-web'
import WASM_URL from '@iroha2/crypto-target-web/wasm-pkg/iroha_crypto_bg.wasm?url'
init(WASM_URL).then(() => {/* ... */})
It would be nice to generate TypeDoc for the whole SDK so it will be possible to explore the API of all packages online.
Signer
class has accountId
field within it. It is located there so that Client
can access it.
I think it doesn't make sense. Signer
should be constructed only from a key pair, because it is the only one essential part for making signatures.
I tried to produce a pending transaction. (Below is the case when we have quorum == 2, but only request the command with 1 private key.)
It has been successfully produced if I check it via getpendingTransaction().
However, the thing here is that (See figure 1 again) it does not give any output. The code is stuck and unable for us to execute any new lines of code.
How I get the tx hash of submitted transaction using transferAsset function?
@scale-codec/definition-compiler
in @iroha2/data-model
FixedPoint<i64>
type in the data model and test it with an actual Iroha2 peerExpression
is a data-model structure that allows to build simple or complex expressions that are evaluated to something at runtime in Iroha.
TODO: show expression examples
Currently Expression
implementation in TypeScript is completely dynamic and cannot guarantee that built Expression
will not fail to evaluate at runtime. However, I think that evaluation mechanism is pretty determined, and Expression
can be described as type-strong discriminated unions, thus, it is possible to develop a type that will compute the resulting type of an expression based on its shape.
I think this feature requires, first of all, improvement of @scale-codec/definition-compiler
so it will generate enum factories that builds a concrete enum variant instead of telling TypeScript that build value is any of variants:
// now:
const val1 = OptionStr('Some', '4')
// type: OptionStr
// should be:
const val2 = OptionStr('Some', '4')
// type (roughly): { tag: 'Some', content: '4' }
This change will allow to give TypeScript precise information about the built enums.
Secondly, iroha-javascript
should provide:
export type EvaluateExpression<E extends Expression> = ... // evaluation prediction
Finally, there should be convenient builders that leverate this util type and will allow to build instructions with checked expressions, which should give a huve DX improvement.
Related issue in Java SDK:
During setup the project on your machine, please make sure that you have initialize npm before install any npm package. Because of npm package modulo update. We should update the README.md file
Hi,
Can anyone confirm or infirm if this package works with react native?
Thanks
It was disabled due to bug in Iroha 2 encountered during development.
Here is the test:
Currently, both __schema__.json
and __generated__.json
are gitignored. However, if some kind of schema reflection is tracked, it would help:
Today, Youssef Mohammad reported an error occuring with Iroha-JS in Iroha Telegram.
js
file:///C:/Users/ASUS/Desktop/crowd-funding/node_modules/@scale-codec/core/dist/lib.mjs:583
throw new Error(`Decode data for discriminant ${discriminant} is undefined; decoders schema: ${formatDecoders(decoders)}`);
^
Error: Decode data for discriminant 85 is undefined; decoders schema: 0 => Decode(...), 1 => Signature(...), 2 => Permission(...), 3 => Evaluate(...), 4 => Find(...), 5 => Conversion(...)
at decodeEnum (file:///C:/Users/ASUS/Desktop/crowd-funding/node_modules/@scale-codec/core/dist/lib.mjs:583:11)
at file:///C:/Users/ASUS/Desktop/crowd-funding/node_modules/@scale-codec/core/dist/lib.mjs:590:22
at trackDecode (file:///C:/Users/ASUS/Desktop/crowd-funding/node_modules/@scale-codec/definition-runtime/dist/lib.mjs:19:61)
at decodeTracked (file:///C:/Users/ASUS/Desktop/crowd-funding/node_modules/@scale-codec/definition-runtime/dist/lib.mjs:238:37)
at WalkerImpl.decode (file:///C:/Users/ASUS/Desktop/crowd-funding/node_modules/@scale-codec/core/dist/lib.mjs:16:19)
at Function.fromBuffer (file:///C:/Users/ASUS/Desktop/crowd-funding/node_modules/@scale-codec/definition-runtime/dist/lib.mjs:243:37)
at Client.request (file:///C:/Users/ASUS/Desktop/crowd-funding/node_modules/@iroha2/client/dist/lib.mjs:350:42)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async ensureDomainExistence (file:///C:/Users/ASUS/Desktop/crowd-funding/client.js:120:18)
at async file:///C:/Users/ASUS/Desktop/crowd-funding/client.js:136:1
Node.js v18.9.0
Details reported:
iroha2-stable
brancheec85ce9
@iroha2/client
ver. 2.0.2uname -a
output: Linux Hyper 5.4.0-125-generic #141-Ubuntu SMP Wed Aug 10 13:42:03 UTC 2022 x86_64 x86_64 x86_64 GNU/LinuxAdd utility methods to build, sign, and send a transaction. Something like:
createTransactionPayload
signTransactionPayload
submitVersionedTransaction
Hello.
I'd like to add the common language guide to the Iroha documentation.
Since Iroha-JS very convenient for the users, it is necessary for the examples.
How stable are the examples displayed in the JavaScript tutorial?
I am mostly interested in:
Potentially, it'll be great to enable these examples as tests, marking the parts useful for the end user with the comments.
Transaction hash might be needed to listen for related events after its submitting.
Currently submit
methods returns Promise<void>
, but it can return a shortcut to get the hash of the submitted transaction.
const txResult = await client.submit(...)
const hash: Uint8Array = txResult.transactionHash()
transactionHash()
is a function to avoid unnecessary hash computations when it is not really needed.
Our colleagues from Fujitsu have asked us to provide assistance in setting up their Iroha interoperability. Their work can be found here.
https://github.com/outSH/iroha2_check
@0x009922, @antyas mentioned that you are working on something similar.
Appending signature to an existing SignedTransaction
is a common operation for multisignature workflows.
The API should look like this:
import { Signer, appendTransactionSignature } from '@iroha2/client'
import { datamodel } from '@iroha2/data-model'
/** @type {datamodel.VersionedSignedTransaction} */
let tx
tx = appendTransactionSignature(tx, keypair)
// or through `Signer`
tx = new Signer(keypair).appendTransactionSignature(tx)
Hello.
It would help the review process if we established a common style for Iroha-JS, for example, using Prettier. It was added long ago for Iroha 2 and I think that copying that idea to the I1 branch would be nice.
Use iroha-ubuntu-latest
in CI/CD
Introduced through: [email protected] › [email protected] › [email protected]
Remediation: No remediation path available.
Introduced through: [email protected] › [email protected] › [email protected] › [email protected]
Remediation: No remediation path available.
grpc
is a dependency of iroha-helpers
(irohaV1) but it's listed under devDependencies
instead of dependencies
. This causes error when user doesn't have grpc installed. Issue occured at our project (Hyperledger Cacti) when we updated from deprecated grpc to grpc-js.
To reproduce initialize empty TS nodejs project, npm i iroha-helpers
(only), compile the following:
import { QueryService_v1Client as QueryService } from "iroha-helpers/lib/proto/endpoint_grpc_pb";
console.log(QueryService.toString());
And run. Error printed:
Error: Cannot find module 'grpc'
Require stack:
- /home/vagrant/tmp/iroha-check/node_modules/iroha-helpers/lib/proto/endpoint_grpc_pb.js
- /home/vagrant/tmp/iroha-check/index.js
at Function.Module._resolveFilename (node:internal/modules/cjs/loader:995:15)
at Function.Module._load (node:internal/modules/cjs/loader:841:27)
at Module.require (node:internal/modules/cjs/loader:1067:19)
at require (node:internal/modules/cjs/helpers:103:18)
at Object.<anonymous> (/home/vagrant/tmp/iroha-check/node_modules/iroha-helpers/lib/proto/endpoint_grpc_pb.js:9:12)
at Module._compile (node:internal/modules/cjs/loader:1165:14)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1219:10)
at Module.load (node:internal/modules/cjs/loader:1043:32)
at Function.Module._load (node:internal/modules/cjs/loader:878:12)
at Module.require (node:internal/modules/cjs/loader:1067:19) {
code: 'MODULE_NOT_FOUND',
requireStack: [
'/home/vagrant/tmp/iroha-check/node_modules/iroha-helpers/lib/proto/endpoint_grpc_pb.js',
'/home/vagrant/tmp/iroha-check/index.js'
]
}
It seems demo link has been broken on README.
Where can I find it?
It is very common to serialise and deserialise bytes to HEX format while working with SDK. So, it makes sense to export a couple of functions for that.
Currently, it is hard to understand how to get the right version of SDK according to the version of Iroha. Having some source of information would help.
Table contents:
Iroha | @iroha2/client & @iroha2/data-model |
Iroha commit |
---|---|---|
2.0.0-pre-rc.9 |
4.0.0 , 4.1.0 |
e3cd89b |
Table should be put in a place independent from the code. Otherwise, it might be not trivial to understand where to patch and where to look for the source of truth, especially when some older versions get patches.
This might be rather a Q&A issue than a bug reporting.
Clone the reporting repository https://github.com/outSH/iroha2_check/tree/7e148419ae1d886a1f41b045bcc4dda1e379bfff and
tsx generate-key.ts
The script, which is trying to utilize generateKeyPairWithConfiguration
, successfully runs
As described in the script https://github.com/outSH/iroha2_check/blob/7e148419ae1d886a1f41b045bcc4dda1e379bfff/generate-key.ts
Now each target has @iroha2/crypto-core
as a dev dependency, but actually it is a major dependency.
Looking for performing permission instruction with typescript, i am not able to found documentation about it in Typescript.
The SDK needs to be built to work with grpc and handle flatbuffers natively
Using some concrete HTTP and WebSocket client limits some usage possibilities.
For HTTP client uses native Fetch API in browser and node-fetch
in node. It is quite lightweight, but it has a set of drawbacks:
And this list can go on and on. It is not a nice decision to handle each possible API extension by extending the client (i.e. iroha client) itself. It would be much nicer if client provides a toolchain to build requests and to handle responses for them.
For WebSocket client currently uses the same approach - native WebSocket in browser, and ws
in node. It has the same set of drawbacks. And it can be solved in the same way.
Multisignature transactions are essential and not obvious to build. It would be useful to have multisignature e2e tests in SDK both to implement that complexity at least once, and to include that code into the documentation (hyperledger/iroha-2-docs#258)
iroha_crypto
if possible@iroha2/data-model
is built on a particular version of Iroha 2, and there might be compatibility issues with other version of how structures are (de)serialised. It might cause confusing errors like #126.
I propose to wrap places where @iroha2/client
makes Torii requests and decodes their responses with code that catches possible decoding errors and prints a meaningful warning with text like "this library targets Iroha 2 version xxx
- please ensure that you're communicating with Iroha of the same version".
Currently, @iroha2/client
provides a mechanism to inject the crypto
instance into the library, so that all crypto-related functions will work after that:
import { setCrypto } from '@iroha2/client'
import { crypto } from '@iroha2/crypto-target-node'
setCrypto(crypto)
The proposal is to move this singleton to the @iroha2/crypto-core
package, because it seems to make more sense:
import { setCryptoWasm } from '@iroha2/crypto-core'
import { cryptoWasm } from '@iroha2/crypto-target-node'
setCryptoWasm(cryptoWasm)
After that, it will be probably possible to move all "interface wrap" into the single core package, and each crypto-target-*
package will be a simple WASM exporter
There might be some unexpected limitations, needs research.
This package has broken dependencies (they are not specified correctly) and not all its API is exposed. In the meanwhile, it is useful e.g. for the documentation to re-use types from this package.
Also, it seems that TupleStruct
variant is not used anymore.
The issue is that some structs, like Signatures
, are sorted. That is, no matter in what order entries are inserted in the map or set (in Rust), when the map or set is encoded, its entries are sorted using PartialEq
trait. It is wise - the exact encoded form has impact on hashing and signing (which could have BTreeMap
metadata, for example). The ordered encoding ensures consistent output despite the insertion order.
The problem is that the JavaScript SDK doesn't perform sorting on encoding, so, signature check failures might be thrown by Iroha if SDK users don't sort some structs content on their own.
Readme needs to be updated to show the inputs into functions.
Last commit was nine months ago, the link to the latest release is not working and you can't even import it into a vanilla node.js project using the github url due to the fact that there's only a .ts file.
Is this project (and HL Iroha along with it) going anywhere?
I'm getting the following error (from node logs):
2023-11-28T19:06:08.554860Z WARN consensus: iroha_core::block::pending: Transaction validation failed
reason=Validation failed caused_by=Some(NotPermitted("TransferExpr { source_id:
AssetId(energy##matias@cognition), object: 12_u32, destination_id: AssetId(energy##pepe@cognition) }:
Unsupported operation"))
This is my dev setup:
Node
: stable-2.0.0-pre-rc.20iroha2/client
: 7.0.0iroha2/data-model
: 7.0.0This is my code:
const transfer = async (from, to, asset, quantity) => {
logger.info(`[srv] transfer ${from} to ${to} ${quantity} of ${asset} ...`);
const [senderAccName, senderDomainId] = from.split('@');
const senderAccId = sugar.accountId(senderAccName, senderDomainId);
const [receiverAccName, receiverDomainId] = to.split('@');
const receiverAccId = sugar.accountId(receiverAccName, receiverDomainId);
const [assetName, assetDomainId] = asset.split('#');
const assetDefId = sugar.assetDefinitionId(assetName, assetDomainId);
const { IdBox } = datamodel;
const { assetId } = sugar;
const senderIdBox = IdBox('AssetId', assetId(senderAccId, assetDefId));
const receiverIdBox = IdBox('AssetId', assetId(receiverAccId, assetDefId));
const value = sugar.value.numericU32(quantity);
const transferAsset = sugar.instruction.transfer(
senderIdBox,
value,
receiverIdBox
);
const instr = sugar.executable.instructions(transferAsset);
const { pre, client } = _clientFactory('matias', 'cognition');
try {
const data = await client.submitExecutable(pre, instr);
logger.info('[srv] transfer completed ...');
return { data };
} catch (error) {
console.log(error);
return { error: error.message };
}
};
Additional information:
The node is created from the following Dockerfile:
# Use the official hyperledger/iroha2 base image with the specified version
FROM hyperledger/iroha2:stable-2.0.0-pre-rc.20
# Set environment variables
ENV TORII_P2P_ADDR 0.0.0.0:1337
ENV TORII_API_URL 0.0.0.0:8080
ENV TORII_TELEMETRY_URL 0.0.0.0:8180
ENV IROHA_PUBLIC_KEY "ed01201C61FAF8FE94E253B93114240394F79A607B7FA55F9E5A41EBEC74B88055768B"
ENV IROHA_PRIVATE_KEY '{"digest_function": "ed25519", "payload": "282ED9F3CF92811C3818DBC4AE594ED59DC1A2F78E4241E31924E101D6B1FB831C61FAF8FE94E253B93114240394F79A607B7FA55F9E5A41EBEC74B88055768B"}'
ENV SUMERAGI_TRUSTED_PEERS '[{"address":"0.0.0.0:1337", "public_key": "ed01201C61FAF8FE94E253B93114240394F79A607B7FA55F9E5A41EBEC74B88055768B"}]'
ENV IROHA_GENESIS_ACCOUNT_PUBLIC_KEY "ed01203F4E3E98571B55514EDC5CCF7E53CA7509D89B2868E62921180A6F57C2F4E255"
ENV IROHA_GENESIS_ACCOUNT_PRIVATE_KEY '{"digest_function": "ed25519", "payload": "038AE16B219DA35AA036335ED0A43C28A2CC737150112C78A7B8034B9D99C9023F4E3E98571B55514EDC5CCF7E53CA7509D89B2868E62921180A6F57C2F4E255"}'
ENV IROHA_GENESIS_WAIT_FOR_PEERS_RETRY_COUNT_LIMIT 100
ENV IROHA_GENESIS_WAIT_FOR_PEERS_RETRY_PERIOD_MS 500
ENV IROHA_GENESIS_GENESIS_SUBMISSION_DELAY_MS 1000
# Expose the required ports
EXPOSE 1337 8080 8180
# Set the working directory
WORKDIR /opt/iroha_data
# Copy the configuration files
COPY ./configs/peer/stable /config
# Command to run on container startup
CMD ["iroha", "--submit-genesis"]
And executed like this:
docker build -t local-iroha .
docker run -d -p 8080:8080 -p 1337:1337 -p 8180:8100 local-iroha
There are two tasks:
The most efficient way to reach this goal and an ultimative solution for this is to completely port iroha_crypto
crate into WASM. It is a big task and requires a lot of refactoring in Rust's sources.
I guess the solution for this will be a special TransactionBuilder
helper that will provide several ways to build a transaction. I don't know how it will be looks like because it depends on how the new @iroha/crypto
package will looks like.
I'm working to stores assets and currently I'm able to register an asset definition of type store, and then set it data with SetKeyValueExpr, but when I query said information, it isn't returned:
Example, this is what I get with the API:
{
"id": {
"definition_id": {
"name": "datastore",
"domain_id": {
"name": "spaceai"
}
},
"account_id": {
"domain_id": {
"name": "spaceai"
},
"name": "admin"
}
},
"value": {
"enum": {
"tag": "Store",
"content": {
"map": {}
}
}
}
}
I cannot see the information I've registered. But I can if I query with iroha_cli_client:
{
"id": "datastore##admin@spaceai",
"value": {
"Store": {
"key": {
"String": "value"
},
"marco": {
"String": "polo"
},
"ping": {
"String": "pong"
}
}
}
}
My environment:
version=2.0.0-pre-rc.20 git_commit_sha="8fa9bc0"
And this is the code used to query data with the API:
const getAsset = async (filter) => {
logger.info(`[srv] getAsset ... ${filter || 'all'}`);
const { pre, client } = _clientFactory('admin', 'spaceai');
const query = sugar.find.allAssets();
try {
const result = await client.requestWithQueryBox(pre, query);
const { tag, content } = result;
if (tag !== 'Ok') return { error: content.enum.content.enum.content };
if (filter) {
const asset = result
.as('Ok')
.batch.enum.as('Vec')
.map((x) => x.enum.as('Identifiable').enum.as('Asset'))
.find((x) => x.id.definition_id.name === filter); // [!code hl]
return { data: asset || 'not found' };
}
const assets = result
.as('Ok')
.batch.enum.as('Vec')
.map((x) => x.enum.as('Identifiable').enum.as('Asset'));
return { data: assets };
} catch (error) {
console.log(error);
return { error: error.message };
}
};
const getBlocksListener = async () => {
const stream = await Torii.listenForBlocksStream(pre, {
// 1 is genesis block, which is committed before each test
height: 0n,
});
return {
/**
* Do an operation that should trigger a block commit,
* and wait until the block is emitted
*/
awaitBlockCommit: async (fn) => {
await Promise.all([stream.ee.once('block'), fn()]);
},
};
};
await blocks.awaitBlockCommit(async () => {
await client.submitExecutable(pre, exec);
});
This code results in a cryptic error message:
iroha::torii::routing: Failed to subscribe to blocks stream error=Error during versioned message decoding
This happens because the code uses 0 instead of 1 to get the genesis block. Inside listenForBlocksStream
we should check that the given height
is in bounds before sending the request to the node
Client package tarball contents:
npm notice 📦 @iroha2/[email protected]
npm notice === Tarball Contents ===
npm notice 2.4kB test/integration/test-node/node_modules/.bin/cross-env
npm notice 2.4kB test/integration/test-node/node_modules/.bin/cross-env-shell
npm notice 2.4kB test/integration/test-node/node_modules/.bin/esr
npm notice 2.0kB test/integration/test-node/node_modules/.bin/vitest
npm notice 337B test/integration/test-web/index.html
npm notice 1.4kB dist-tsc/blocks-stream.js
npm notice 8.2kB dist-tsc/client.js
npm notice 712B dist-tsc/collect-garbage.js
npm notice 838B test/integration/test-web/cypress/support/commands.js
npm notice 418B dist-tsc/const.js
npm notice 135B dist-tsc/crypto-singleton.js
npm notice 1.4kB dist-tsc/events.js
npm notice 996B test/integration/test-web/cypress/plugins/index.js
npm notice 670B test/integration/test-web/cypress/support/index.js
npm notice 14.6kB dist/lib.cjs.js
npm notice 12.5kB dist/lib.esm.js
npm notice 283B dist-tsc/lib.js
npm notice 2.7kB dist-tsc/util.js
npm notice 156B api-extractor.json
npm notice 488B test/integration/config/client_config.json
npm notice 68B test/integration/test-web/cypress.json
npm notice 1.9kB package.json
npm notice 481B test/integration/test-node/package.json
npm notice 1.1kB test/integration/test-web/package.json
npm notice 1.3kB test/integration/config/peer_config.json
npm notice 2.4kB test/integration/config/peer_genesis.json
npm notice 151B test/integration/test-web/cypress/tsconfig.json
npm notice 382B test/integration/test-web/tsconfig.json
npm notice 203B tsconfig.json
npm notice 1.1kB test/integration/test-node/node_modules/.pnpm-debug.log
npm notice 610B dist-tsc/blocks-stream.d.ts.map
npm notice 2.3kB dist-tsc/client.d.ts.map
npm notice 404B dist-tsc/collect-garbage.d.ts.map
npm notice 398B dist-tsc/const.d.ts.map
npm notice 270B dist-tsc/crypto-singleton.d.ts.map
npm notice 610B dist-tsc/events.d.ts.map
npm notice 23.8kB dist/lib.cjs.js.map
npm notice 200B dist-tsc/lib.d.ts.map
npm notice 23.3kB dist/lib.esm.js.map
npm notice 914B dist-tsc/util.d.ts.map
npm notice 2.4kB CHANGELOG.md
npm notice 120B test/integration/test-node/CHANGELOG.md
npm notice 188B test/integration/test-web/CHANGELOG.md
npm notice 741B README.md
npm notice 303B test/integration/README.md
npm notice 637B dist-tsc/blocks-stream.d.ts
npm notice 1.9kB src/blocks-stream.ts
npm notice 2.7kB dist-tsc/client.d.ts
npm notice 9.4kB src/client.ts
npm notice 1.2kB test/integration/test-web/src/client.ts
npm notice 324B dist-tsc/collect-garbage.d.ts
npm notice 820B src/collect-garbage.ts
npm notice 527B dist-tsc/const.d.ts
npm notice 410B src/const.ts
npm notice 250B dist-tsc/crypto-singleton.d.ts
npm notice 277B src/crypto-singleton.ts
npm notice 90B test/integration/test-web/src/crypto.ts
npm notice 251B test/integration/test-web/etc/dev-peer-server.ts
npm notice 276B test/integration/test-web/src/env.d.ts
npm notice 632B dist-tsc/events.d.ts
npm notice 1.7kB src/events.ts
npm notice 317B test/integration/config/index.ts
npm notice 192B src/json-bigint-shim.d.ts
npm notice 316B dist-tsc/lib.d.ts
npm notice 4.8kB dist/lib.d.ts
npm notice 280B src/lib.ts
npm notice 977B test/integration/test-web/cypress/integration/main.ts
npm notice 276B test/integration/test-web/src/main.ts
npm notice 141B test/integration/test-web/etc/meta.ts
npm notice 13.6kB test/integration/test-node/multiple.spec.ts
npm notice 200B test/integration/prepare-peer.ts
npm notice 554B test/integration/test-web/etc/test-run.ts
npm notice 859B dist-tsc/util.d.ts
npm notice 2.9kB src/util.ts
npm notice 106B test/integration/util.ts
npm notice 1.3kB test/integration/test-web/vite.config.ts
npm notice 162B test/integration/test-node/vitest.config.ts
npm notice 375B test/integration/test-web/src/App.vue
npm notice 1.7kB test/integration/test-web/src/components/CreateDomain.vue
npm notice 2.0kB test/integration/test-web/src/components/Listener.vue
npm notice 491B test/integration/test-web/src/components/StatusChecker.vue
npm notice 64B test/integration/test-web/pnpm-global/5/pnpm-lock.yaml
npm notice 11.3kB LICENSE
npm notice === Tarball Details ===
npm notice name: @iroha2/client
npm notice version: 1.2.0
npm notice package size: 38.7 kB
npm notice unpacked size: 185.1 kB
npm notice shasum: c470713a0ebf68566a1d210337ee7efa4b2eea57
npm notice integrity: sha512-MfVY8ctMlFSfv[...]1nieBy/Ner17w==
npm notice total files: 83
npm notice
+ @iroha2/[email protected]
It is not OK. Other packages should be inspected as well.
Matías Salimbene reported an issue with types in Iroha JS SDK today.
Transaction validation failed reason=Validation failed caused_by=Some(InstructionFailed(Evaluate(Type(AssetValueType(Mismatch { expected: Fixed, actual: Quantity })))))
The valueType is correctly registered as Quantity
(not Fixed).
"value_type": {
"enum": {
"tag": "Quantity"
}
}
Additionaly, Matías gets an error if he doesn't provide the quantity with decimal precision, i.e quantity: "100"
fails, but quantity:"100.0"
is fine. He'd like to know whether this should be expected.
Provided context:
stable-2.0.0-pre-rc.20
client/data model
: ^7.0.0
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.