Giter Site home page Giter Site logo

everx-labs / ever-sdk Goto Github PK

View Code? Open in Web Editor NEW
164.0 18.0 52.0 19.61 MB

Client Libraries in 13 languages for Everscale, TON, Venom and other TVM blockchains

Home Page: https://docs.everos.dev/ever-sdk/

License: Apache License 2.0

Rust 93.65% JavaScript 0.39% C 0.08% TypeScript 2.13% Solidity 3.75%
sdk blockchain freeton client everscale ever web3 toncoin ton venom

ever-sdk's Introduction

Ever SDK

Client libraries for DApp development in TVM blockchains (Everscale, Gosh, TON, Venom Blockchain, etc.).

Core Ever-SDK client library is written in Rust, with bindings in 11 programming languages.

Get quick help in our telegram channel:

Channel on Telegram

Supported languages

Rust (core library)

Repository: https://github.com/everx-labs/ever-sdk

What is Core Client Library?

Core Client Library is written in Rust that can be dynamically linked. It provides all heavy-computation components and functions, such as TON Virtual Machine, TON Transaction Executor, ABI-related functions, boc-related functions, crypto functions.

The decision to create the Rust library was made after a period of time using pure JavaScript to implement these use cases.

We ended up with very slow work of pure JavaScript and decided to move all this to Rust library and link it to Javascript as a compiled binary including a wasm module for browser applications.

Also, this approach provided an opportunity to easily create bindings for any programming language and platform, thus, to make it possible to develop distributed applications (DApps) for any possible use-cases, such as: mobile DApps, web DApps, server-side DApps, enterprise DApp etc.

Client Library exposes all the functionality through a few of exported functions. All interaction with library is performed using JSON-RPC like protocol.

Official Javascript(Typescript) binding

Repository: JavaScript SDK

You need to install core package and the package with binary for your platform. See the documentation.

Platform Package
core package for all platforms @eversdk/core
Node.js @eversdk/lib-node
Web @eversdk/lib-web
React-Native @eversdk/lib-react-native
React-Native with JSI support @eversdk/lib-react-native-jsi

Community bindings

Language Repository
Clojure serge-medvedev/tonos-client-clojure
Golang

radianceteam/ton-client-go
markgenuine/ever-client-go

Java

radianceteam/ton-client-java
laugan/java4ever-binding

Kotlin mdorofeev/ton-client-kotlin
Lua serge-medvedev/tonos-client-lua
.NET everscale-actions/everscale-dotnet
PHP

extraton/php-ton-client
radianceteam/ton-client-php

Python move-ton/ton-client-py
Ruby nerzh/ton-client-ruby
Scala radianceteam/ton-client-scala
Swift nerzh/ton-client-swift

If you did not find the language you need

  • use library module json_interface which provides access to library functions through JSON-RPC interface. This interface exports several extern "C" functions. So you can build a dynamic or static link library and link it to your application as any other external libraries. The JSON Interface is fully "C" compliant. You can find description in section JSON Interface.
  • write your own binding to chosen language and share it with community.

If you choose using JSON Interface please read this document JSON Interface.
Here you can find directions how to use json_interface and write your own binding.

Use-cases

With Ever-SDK you can implement logic of any complexity on TVM compatible blockchains (Everscale, Gosh, TON, Venom, etc.).

  • Create and send messages to blockchain
  • Process messages reliably (supports retries and message expiration mechanics)
  • Supports TON Solidity and ABI compatible contracts
  • Emulate transactions locally
  • Run get methods
  • Get account state
  • Query blockchain data (blocks, transactions, messages)
  • Subscribe to events and any other blockchain updates (literally)
  • Sign data/check signature, calculate hashes (sha256, sha512), encrypt/decrypt data
  • Validate addresses
  • Work with blockchain native types (bag of cells or BOCs): encode, decode, calculate hash, etc
  • Works on top of GraphQL API and compatible with Evernode-SE/DS, Evercloud.

Quick Start

Get your endpoint at dashboard.evercloud.dev or run Evernode-SE (local node) or Dapp Server (self-hosted blockchain node).

See the list of available TVM networks: https://docs.everplatform.dev/products/evercloud/networks-endpoints

Quick Start (Javascript binding)

Error descriptions

JavaScript SDK Types and Methods (API Reference)

Core Types and Methods (API Reference)

Guides

How to avoid Soft Breaking Problems

Soft Breaking is API changes that include only new optional fields in the existing structures. These changes are fully backward compatible for JSON Interface.

But in Rust such changes can produce some problems with an old client code.

Look at the example below:

  1. There is an API v1.0 function foo and the corresponding params structure:
#[derive(Default)]
struct ParamsOfFoo {
    pub foo: String,
}

pub fn foo(params: ParamsOfFoo)
  1. Application uses this function in this way:
foo(ParamsOfFoo {
    foo: "foo".into(),
});
  1. API v.1.1 introduces new field in ParamsOfFoo:
#[derive(Default)]
struct ParamsOfFoo {
    pub foo: String,
    pub bar: Option<String>,
}

From the perspective of JSON-interface it isn't breaking change because the new parameter is optional. But code snippet (2) will produce Rust compilation error.

  1. To avoid such problems we recommend to use default implementation inside structure initialisation:
foo(ParamsOfFoo {
    foo: "foo".into(),
    ..Default::default(),
});

For all Ton Client API structures Default trait is implemented.

Build client library

The best way to build client libraries is to use build scripts from this repo.

Note: The scripts are written in JavaScript, so you have to install Node.js (v.10 or newer) to run them. Also make sure you have the latest version of Rust installed.

To build a binary for a specific target (or binding), navigate to the relevant folder and run node build.js.

The resulting binaries are placed to bin folder in the gz-compressed format.

Note that the build script generates binaries compatible with the platform used to run the script. For example, if you run it on macOS, you get binaries targeted at Darwin (macOS) platform.

Note: You need latest version of rust. Upgrade it with rustup update command. Check version with rustc --version, it should be above or equal to 1.47.0.

Build artifacts

Rebuild api.json:

cd evercli
cargo run api -o ../tools

Rebuild docs:

cd tools
npm i
tsc
node index docs -o ../docs

Rebuild modules.ts:

cd tools
npm i
tsc
node index binding -l ts -o ../../ever-sdk-js/packages/core/src

Run tests

To run test suite use standard Rust test command

cargo test

SDK tests need EVER OS API endpoint to run on. Such an API is exposed by a DApp Server which runs in real networks and by local blockchain Evernode SE.

Evernode SE is used by default with address http://localhost and port 80. If you launch it on another port you need to specify it explicitly like this: http://localhost:port. If you have Evernode SE running on another address or if you need to run tests on a real Everscale network, use the following environment variables to override the default parameters

TON_USE_SE: true/false - flag defining if tests run against Evernode SE or a real network (DApp Server)
TON_NETWORK_ADDRESS - Dapp server or Evernode SE addresses separated by comma.
TON_GIVER_SECRET - Giver secret key. If not defined, default Evernode SE giver keys are used
TON_GIVER_ADDRESS - Address of the giver to use for prepaying accounts before deploying test contracts. If not defined, the address is calculated using `GiverV2.tvc` and configured public key
EVERCLOUD_AUTH_PROJECT – Evercloud project id used to authorise tests that requires main net interaction 

Download precompiled binaries

Instead of building library yourself, you can download the latest precompiled binaries from EverX SDK Binaries Store.

Platform Major Download links
Win32 0 ever_client.lib, ever_client.dll
1 ever_client.lib, ever_client.dll
macOS 0 libton_client.dylib
1 (x86_64)libton_client.dylib
1 (aarch64)libton_client.dylib
Linux 0 libton_client.so
1 libton_client.so

If you want an older version of library (e.g. 0.25.0 for macOS), you need to choose a link to your platform from the list above and replace 0 with a version: https://binaries.everx-labs.io/tonclient_0_25_0_darwin.gz

Downloaded archive is gzipped file

ever-sdk's People

Contributors

50c3 avatar a-zorina avatar aifreeway avatar alex-novikov-1990 avatar alexeyvavilin avatar amphyby avatar andrey-kurochkin avatar andy-a-o avatar aslanin avatar astilster avatar atomxy avatar bvscd avatar ch1sel avatar d3p avatar diserere avatar elasticlove1 avatar futurizt avatar g9d avatar igorkoval avatar joydark avatar keshoid avatar levigot avatar markgenuine avatar melsomino avatar mikhailushakoff avatar risentveber avatar serge-medvedev avatar sumrachek avatar tonjen avatar yaroslavser avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ever-sdk's Issues

Linux arm64 binary

Please add the Linux arm64 target to the build pipeline.
This is needed for running applications natively in Docker on macOS since amd64 emulation isn't working for that.

Need a flag for unlimited gas

Due to the hardcoded gas limit some heavy get methods can't be executed. For example getVotesPerJuror in FreeTonContest contract. It fails with error Local run failed: VM Exception: out of gas, code 13, value: 1000000026.
Maybe additional flag to disable gas limit will be useful.

Invalid TVC image: Invalid byte 10, offset 60.

Library version: 1.1.0

I'm trying to replicate the tests from /ton_client/client/src/abi/tests.rs in Ruby
All the tests but this one work:

    #[test]
    fn encode_v2() {
        TestClient::init_log();
        let client = TestClient::new();
        let (events_abi, events_tvc) = TestClient::package(EVENTS, Some(2));
        let keys = KeyPair {
            public: "4c7c408ff1ddebb8d6405ee979c716a14fdd6cc08124107a61d3c25597099499".into(),
            secret: "cc8929d635719612a9478b9cd17675a39cfad52d8959e8a177389b8c0b9122a7".into(),
        };
        let abi = events_abi.clone();
        let time: u64 = 1599458364291;
        let expire: u32 = 1599458404;


        let deploy_params = |signing: Signer| ParamsOfEncodeMessage {
            abi: abi.clone(),
            address: None,
            deploy_set: Some(DeploySet {
                workchain_id: None,
                tvc: events_tvc.clone(),
                initial_data: None,
            }),
            call_set: Some(CallSet {
                function_name: "constructor".into(),
                header: Some(FunctionHeader {
                    pubkey: signing.resolve_public_key().unwrap(),
                    time: Some(time),
                    expire: Some(expire),
                }),
                input: None,
            }),
            signer: signing,
            processing_try_index: None,
        };

        let unsigned: ResultOfEncodeMessage = client.request(
            "abi.encode_message",
            deploy_params(Signer::External {
                public_key: keys.public.clone(),
            }),
        ).unwrap();
        assert_eq!(unsigned.message, "te6ccgECFwEAA2gAAqeIAAt9aqvShfTon7Lei1PVOhUEkEEZQkhDKPgNyzeTL6YSEZTHxAj/Hd67jWQF7peccWoU/dbMCBJBB6YdPCVZcJlJkAAAF0ZyXLg19VzGRotV8/gGAQEBwAICA88gBQMBAd4EAAPQIABB2mPiBH+O713GsgL3S844tQp+62YECSCD0w6eEqy4TKTMAib/APSkICLAAZL0oOGK7VNYMPShCQcBCvSkIPShCAAAAgEgDAoByP9/Ie1E0CDXScIBjhDT/9M/0wDRf/hh+Gb4Y/hijhj0BXABgED0DvK91wv/+GJw+GNw+GZ/+GHi0wABjh2BAgDXGCD5AQHTAAGU0/8DAZMC+ELiIPhl+RDyqJXTAAHyeuLTPwELAGqOHvhDIbkgnzAg+COBA+iogggbd0Cgud6S+GPggDTyNNjTHwH4I7zyudMfAfAB+EdukvI83gIBIBINAgEgDw4AvbqLVfP/hBbo417UTQINdJwgGOENP/0z/TANF/+GH4Zvhj+GKOGPQFcAGAQPQO8r3XC//4YnD4Y3D4Zn/4YeLe+Ebyc3H4ZtH4APhCyMv/+EPPCz/4Rs8LAMntVH/4Z4AgEgERAA5biABrW/CC3Rwn2omhp/+mf6YBov/ww/DN8Mfwxb30gyupo6H0gb+j8IpA3SRg4b3whXXlwMnwAZGT9ghBkZ8KEZ0aCBAfQAAAAAAAAAAAAAAAAACBni2TAgEB9gBh8IWRl//wh54Wf/CNnhYBk9qo//DPAAxbmTwqLfCC3Rwn2omhp/+mf6YBov/ww/DN8Mfwxb2uG/8rqaOhp/+/o/ABkRe4AAAAAAAAAAAAAAAAIZ4tnwOfI48sYvRDnhf/kuP2AGHwhZGX//CHnhZ/8I2eFgGT2qj/8M8AIBSBYTAQm4t8WCUBQB/PhBbo4T7UTQ0//TP9MA0X/4Yfhm+GP4Yt7XDf+V1NHQ0//f0fgAyIvcAAAAAAAAAAAAAAAAEM8Wz4HPkceWMXohzwv/yXH7AMiL3AAAAAAAAAAAAAAAABDPFs+Bz5JW+LBKIc8L/8lx+wAw+ELIy//4Q88LP/hGzwsAye1UfxUABPhnAHLccCLQ1gIx0gAw3CHHAJLyO+Ah1w0fkvI84VMRkvI74cEEIoIQ/////byxkvI84AHwAfhHbpLyPN4=");

The error, in Ruby:

{
    "code"=>308, 
    "message"=>"Invalid TVC image: Invalid byte 10, offset 60.", "data"=>{"core_version"=>"1.1.0"}
}

Yes, I'm using base64.encode(content of #{DATA_DIR}/contracts/abi_v2/Events.tvc) in Ruby

I've tried replacing #{DATA_DIR}/contracts/abi_v2/Events.tvc with a new fresher one.

"Invalid parameters: missing field `type` at line 1 column" -- for tests in Abi

Library version: 1.0.0

I'm writting tests for Abi in Ruby by replicating the ones written in Rust https://github.com/tonlabs/TON-SDK/blob/master/ton_client/client/src/abi/tests.rs

I'll always get this, for encode and decode ones:

{"code"=>23, "message"=>"Invalid parameters: missing field `type` at line 1 column 612\nparams: [here is JSON]}

The fields type, where they exist in Events.abi.json, are being read and sent out, it can be seen in the full output:

{"code"=>23, "message"=>"Invalid parameters: missing field `type` at line 1 column 612\nparams: {\"abi\":{\"ABI version\":2,\"header\":[\"pubkey\",\"time\",\"expire\"],\"functions\":[{\"name\":\"emitValue\",\"inputs\":[{\"name\":\"id\",\"type\":\"uint256\",\"components\":[]}],\"outputs\":[],\"id\":null},{\"name\":\"returnValue\",\"inputs\":[{\"name\":\"id\",\"type\":\"uint256\",\"components\":[]}],\"outputs\":[{\"name\":\"value0\",\"type\":\"uint256\",\"components\":[]}],\"id\":null},{\"name\":\"sendAllMoney\",\"inputs\":[{\"name\":\"dest_addr\",\"type\":\"address\",\"components\":[]}],\"outputs\":[],\"id\":null},{\"name\":\"constructor\",\"inputs\":[],\"outputs\":[],\"id\":null}],\"events\":[{\"name\":\"EventThrown\",\"inputs\":[{\"name\":\"id\",\"type\":\"uint256\",\"components\":[]}],\"id\":null}],\"data\":[]},\"address\":null,\"deploy_set\":{\"tvc\":\"te6ccgECFwEAAxUAAgE0BgEBAcACAgPPIAUDAQHeBAAD0CAAQdgAAAAAAAAA\\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAIm/wD0pCAiwAGS9KDhiu1TWDD0\\noQkHAQr0pCD0oQgAAAIBIAwKAcj/fyHtRNAg10nCAY4Q0//TP9MA0X/4Yfhm\\n+GP4Yo4Y9AVwAYBA9A7yvdcL//hicPhjcPhmf/hh4tMAAY4dgQIA1xgg+QEB\\n0wABlNP/AwGTAvhC4iD4ZfkQ8qiV0wAB8nri0z8BCwBqjh74QyG5IJ8wIPgj\\ngQPoqIIIG3dAoLnekvhj4IA08jTY0x8B+CO88rnTHwHwAfhHbpLyPN4CASAS\\nDQIBIA8OAL26i1Xz/4QW6ONe1E0CDXScIBjhDT/9M/0wDRf/hh+Gb4Y/hijh\\nj0BXABgED0DvK91wv/+GJw+GNw+GZ/+GHi3vhG8nNx+GbR+AD4QsjL//hDzw\\ns/+EbPCwDJ7VR/+GeAIBIBEQAOW4gAa1vwgt0cJ9qJoaf/pn+mAaL/8MPwzf\\nDH8MW99IMrqaOh9IG/o/CKQN0kYOG98IV15cDJ8AGRk/YIQZGfChGdGggQH0\\nAAAAAAAAAAAAAAAAAAgZ4tkwIBAfYAYfCFkZf/8IeeFn/wjZ4WAZPaqP/wzw\\nAMW5k8Ki3wgt0cJ9qJoaf/pn+mAaL/8MPwzfDH8MW9rhv/K6mjoaf/v6PwAZ\\nEXuAAAAAAAAAAAAAAAACGeLZ8DnyOPLGL0Q54X/5Lj9gBh8IWRl//wh54Wf/\\nCNnhYBk9qo//DPACAUgWEwEJuLfFglAUAfz4QW6OE+1E0NP/0z/TANF/+GH4\\nZvhj+GLe1w3/ldTR0NP/39H4AMiL3AAAAAAAAAAAAAAAABDPFs+Bz5HHljF6\\nIc8L/8lx+wDIi9wAAAAAAAAAAAAAAAAQzxbPgc+SVviwSiHPC//JcfsAMPhC\\nyMv/+EPPCz/4Rs8LAMntVH8VAAT4ZwBy3HAi0NYCMdIAMNwhxwCS8jvgIdcN\\nH5LyPOFTEZLyO+HBBCKCEP////28sZLyPOAB8AH4R26S8jze\\n\",\"workchain_id\":null,\"initial_data\":null},\"call_set\":{\"function_name\":\"constructor\",\"header\":{\"expire\":1599458404,\"time\":1599458364291,\"pubkey\":\"4c7c408ff1ddebb8d6405ee979c716a14fdd6cc08124107a61d3c25597099499\"},\"input\":null},\"signer\":{\"type\":\"External\",\"public_key\":\"4c7c408ff1ddebb8d6405ee979c716a14fdd6cc08124107a61d3c25597099499\"},\"processing_try_index\":null}", "data"=>{"core_version"=>"1.0.0"}}

Can't build web version if not authenticated on github with SSH key

Steps to reproduce

git clone https://github.com/tonlabs/TON-SDK
cd TON-SDK/ton_client/platforms/ton-client-web/
node build.js

Output

ton-client-web# node build.js
    Updating crates.io index
    Updating git repository `https://github.com/tonlabs/bip39-rs.git`
    Updating git repository `https://github.com/tonlabs/ton-labs-block.git`
    Updating git repository `https://github.com/tonlabs/ton-labs-types.git`
    Updating git repository `https://github.com/tonlabs/ton-labs-vm.git`
    Updating git repository `https://github.com/tonlabs/ton-labs-abi.git`
    Updating git repository `ssh://[email protected]/tonlabs/ton-executor.git`
error: failed to load source for a dependency on `ton_executor`

Caused by:
  Unable to update ssh://[email protected]/tonlabs/ton-executor.git

Caused by:
  failed to clone into: /root/.cargo/git/db/ton-executor-655470c1b050fd42

Caused by:
  failed to authenticate when downloading repository
attempted ssh-agent authentication, but none of the usernames `git` succeeded

Caused by:
  error authenticating: no auth sock variable; class=Ssh (23)
undefined

env info

uname -a
Linux vird-MS-7881 5.3.0-40-generic #32~18.04.1-Ubuntu SMP Mon Feb 3 14:05:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
rustc -V
rustc 1.40.0 (73528e339 2019-12-16)
node -v
v12.13.0

nodejs installed with nvm, rust with rustup

recursion limit ?

I use sync version of method tvm.run_get

Снимок экрана 2023-08-02 в 02 55 12

call this method like this

out = run_get_method(addr: "-1:3333333333333333333333333333333333333333333333333333333333333333",
                     method_name: "participant_list_extended")

and I have this error:

   Can't serialize result: recursion limit exceeded at line 1 column 29634

async version works fine

Add function for AES encryption to sdk

Popular AES Encryption is missing in current crypto module implementation.
AES Encryption should support:

  • 128-bit, 192-bit and 256-bit key sizes.
  • CBC, CFB, CTR, ECB and OFB modes.

The Electronic Codebook Mode (ECB)
The Electronic Codebook (ECB) mode is a confidentiality mode that features, for a given key,
the assignment of a fixed ciphertext block to each plaintext block, analogous to the assignment of
code words in a codebook. The Electronic Codebook (ECB) mode is defined as follows:
alt text
In ECB encryption, the forward cipher function is applied directly and independently to each
block of the plaintext. The resulting sequence of output blocks is the ciphertext.
In ECB decryption, the inverse cipher function is applied directly and independently to each
block of the ciphertext. The resulting sequence of output blocks is the plaintext.
alt text
In ECB encryption and ECB decryption, multiple forward cipher functions and inverse cipher
functions can be computed in parallel.
In the ECB mode, under a given key, any given plaintext block always gets encrypted to the
9same ciphertext block. If this property is undesirable in a particular application, the ECB mode
should not be used.

The Cipher Block Chaining Mode (CBC)
The Cipher Block Chaining (CBC) mode is a confidentiality mode whose encryption process
features the combining (“chaining”) of the plaintext blocks with the previous ciphertext blocks.
The CBC mode requires an IV to combine with the first plaintext block. The IV need not be
secret, but it must be unpredictable; the generation of such IVs is discussed in Appendix C.
Also, the integrity of the IV should be protected, as discussed in Appendix D. The CBC mode is
defined as follows:
alt text
In CBC encryption, the first input block is formed by exclusive-ORing the first block of the
plaintext with the IV. The forward cipher function is applied to the first input block, and the
resulting output block is the first block of the ciphertext. This output block is also exclusive-
ORed with the second plaintext data block to produce the second input block, and the forward
cipher function is applied to produce the second output block. This output block, which is the
second ciphertext block, is exclusive-ORed with the next plaintext block to form the next input
block. Each successive plaintext block is exclusive-ORed with the previous output/ciphertext
block to produce the new input block. The forward cipher function is applied to each input block
to produce the ciphertext block.
In CBC decryption, the inverse cipher function is applied to the first ciphertext block, and the
resulting output block is exclusive-ORed with the initialization vector to recover the first
plaintext block. The inverse cipher function is also applied to the second ciphertext block, and
the resulting output block is exclusive-ORed with the first ciphertext block to recover the second
plaintext block. In general, to recover any plaintext block (except the first), the inverse cipher
function is applied to the corresponding ciphertext block, and the resulting block is exclusive-
ORed with the previous ciphertext block.
In CBC encryption, the input block to each forward cipher operation (except the first) depends on
the result of the previous forward cipher operation, so the forward cipher operations cannot be
performed in parallel. In CBC decryption, however, the input blocks for the inverse cipher
function, i.e., the ciphertext blocks, are immediately available, so that multiple inverse cipher
operations can be performed in parallel.

The Cipher Feedback Mode (CFB)
The Cipher Feedback (CFB) mode is a confidentiality mode that features the feedback of
successive ciphertext segments into the input blocks of the forward cipher to generate output
blocks that are exclusive-ORed with the plaintext to produce the ciphertext, and vice versa. The
CFB mode requires an IV as the initial input block. The IV need not be secret, but it must be
unpredictable; the generation of such IVs is discussed in Appendix C.
The CFB mode also requires an integer parameter, denoted s, such that 1 ≤ s ≤ b. In the
specification of the CFB mode below, each plaintext segment (P j ) and ciphertext segment (C j )
consists of s bits. The value of s is sometimes incorporated into the name of the mode, e.g., the
1-bit CFB mode, the 8-bit CFB mode, the 64-bit CFB mode, or the 128-bit CFB mode.
The CFB mode is defined as follows:
alt text
In CFB encryption, the first input block is the IV, and the forward cipher operation is applied to
the IV to produce the first output block. The first ciphertext segment is produced by exclusive-
ORing the first plaintext segment with the s most significant bits of the first output block. (The
remaining b-s bits of the first output block are discarded.) The b-s least significant bits of the IV
are then concatenated with the s bits of the first ciphertext segment to form the second input
block. An alternative description of the formation of the second input block is that the bits of
the first input block circularly shift s positions to the left, and then the ciphertext segment
replaces the s least significant bits of the result.
The process is repeated with the successive input blocks until a ciphertext segment is produced
from every plaintext segment. In general, each successive input block is enciphered to produce
an output block. The s most significant bits of each output block are exclusive-ORed with the
corresponding plaintext segment to form a ciphertext segment. Each ciphertext segment (except
the last one) is “fed back” into the previous input block, as described above, to form a new input
block.
alt text
In CFB decryption, the IV is the first input block, and each successive input block is formed as in
CFB encryption, by concatenating the b-s least significant bits of the previous input block with
the s most significant bits of the previous ciphertext. The forward cipher function is applied to
each input block to produce the output blocks. The s most significant bits of the output blocks
are exclusive-ORed with the corresponding ciphertext segments to recover the plaintext
segments.
In CFB encryption, like CBC encryption, the input block to each forward cipher function (except
the first) depends on the result of the previous forward cipher function; therefore, multiple
forward cipher operations cannot be performed in parallel. In CFB decryption, the required
forward cipher operations can be performed in parallel if the input blocks are first constructed (in
series) from the IV and the ciphertext.

The Output Feedback Mode (OFB)
The Output Feedback (OFB) mode is a confidentiality mode that features the iteration of the
forward cipher on an IV to generate a sequence of output blocks that are exclusive-ORed with
the plaintext to produce the ciphertext, and vice versa. The OFB mode requires that the IV is a
nonce, i.e., the IV must be unique for each execution of the mode under the given key; the
generation of such IVs is discussed in Appendix C. The OFB mode is defined as follows:
alt text
In OFB encryption, the IV is transformed by the forward cipher function to produce the first
output block. The first output block is exclusive-ORed with the first plaintext block to produce
the first ciphertext block. The forward cipher function is then invoked on the first output block
to produce the second output block. The second output block is exclusive-ORed with the second
plaintext block to produce the second ciphertext block, and the forward cipher function is
invoked on the second output block to produce the third output block. Thus, the successive
output blocks are produced from applying the forward cipher function to the previous output
blocks, and the output blocks are exclusive-ORed with the corresponding plaintext blocks to
produce the ciphertext blocks. For the last block, which may be a partial block of u bits, the
most significant u bits of the last output block are used for the exclusive-OR operation; the
remaining b-u bits of the last output block are discarded.
In OFB decryption, the IV is transformed by the forward cipher function to produce the first
output block. The first output block is exclusive-ORed with the first ciphertext block to recover
the first plaintext block. The first output block is then transformed by the forward cipher
function to produce the second output block. The second output block is exclusive-ORed with
the second ciphertext block to produce the second plaintext block, and the second output block is
also transformed by the forward cipher function to produce the third output block. Thus, the
successive output blocks are produced from applying the forward cipher function to the previous
output blocks, and the output blocks are exclusive-ORed with the corresponding ciphertext
blocks to recover the plaintext blocks. For the last block, which may be a partial block of u bits,
the most significant u bits of the last output block are used for the exclusive-OR operation; the
remaining b-u bits of the last output block are discarded.
alt text
In both OFB encryption and OFB decryption, each forward cipher function (except the first)
depends on the results of the previous forward cipher function; therefore, multiple forward cipher
functions cannot be performed in parallel. However, if the IV is known, the output blocks can be
generated prior to the availability of the plaintext or ciphertext data.
The OFB mode requires a unique IV for every message that is ever encrypted under the given
key. If, contrary to this requirement, the same IV is used for the encryption of more than one
message, then the confidentiality of those messages may be compromised. In particular, if a
plaintext block of any of these messages is known, say, the jth plaintext block, then the jth output
of the forward cipher function can be determined easily from the jth ciphertext block of the
message. This information allows the jth plaintext block of any other message that is encrypted
using the same IV to be easily recovered from the jth ciphertext block of that message.
Confidentiality may similarly be compromised if any of the input blocks to the forward cipher
function for the encryption of a message is designated as the IV for the encryption of another
message under the given key.

The Counter Mode (CTR)
The Counter (CTR) mode is a confidentiality mode that features the application of the forward
cipher to a set of input blocks, called counters, to produce a sequence of output blocks that are
exclusive-ORed with the plaintext to produce the ciphertext, and vice versa. The sequence of
counters must have the property that each block in the sequence is different from every other
block. This condition is not restricted to a single message: across all of the messages that are
encrypted under the given key, all of the counters must be distinct. In this recommendation, the
counters for a given message are denoted T 1 , T 2 , ... , T n . Methods for generating counters are
discussed in Appendix B. Given a sequence of counters, T 1 , T 2 , ... , T n , the CTR mode is
defined as follows:
alt text
In CTR encryption, the forward cipher function is invoked on each counter block, and the
resulting output blocks are exclusive-ORed with the corresponding plaintext blocks to produce
the ciphertext blocks. For the last block, which may be a partial block of u bits, the most
significant u bits of the last output block are used for the exclusive-OR operation; the remaining
b-u bits of the last output block are discarded.
In CTR decryption, the forward cipher function is invoked on each counter block, and the
resulting output blocks are exclusive-ORed with the corresponding ciphertext blocks to recover
the plaintext blocks. For the last block, which may be a partial block of u bits, the most
significant u bits of the last output block are used for the exclusive-OR operation; the remaining
b-u bits of the last output block are discarded.
In both CTR encryption and CTR decryption, the forward cipher functions can be performed in
parallel; similarly, the plaintext block that corresponds to any particular ciphertext block can be
recovered independently from the other plaintext blocks if the corresponding counter block can
be determined. Moreover, the forward cipher functions can be applied to the counters prior to the
availability of the plaintext or ciphertext data.
alt text

crypto.factorize panic

crypto.factorize {"composite":"10"} fails with thread 'tokio-runtime-worker' panicked at 'attempt to shift left with overflow', ton_client/client/src/crypto/math.rs:105:19

[minor stuff] api.json update for tag

Tag 1.5.1 created, but api.json still contains version 1.5.0.

Expected is: api.json to contain the exact tag version.

Possible solution is to re-generate api.json before creating new tag (via some pipeline script).

The precompiled `tonclient.so` cannot be linked with GLIBC_2.17

This might be a preview for a PR (currently it only loads the pre-compiled tonclient.so or dll into the Java JVM).
I've managed to load system-wide & also packaged (extracted from JAR) native assembly in a pure Java/Gradle project.

The issue is that it fails to link the library with glibc 2.17:

> Task :library:compileJava
> Task :library:processResources UP-TO-DATE
> Task :library:classes
> Task :library:compileTestJava UP-TO-DATE
> Task :library:processTestResources NO-SOURCE
> Task :library:testClasses UP-TO-DATE
> Task :library:test FAILED
> assembly extracted: /tmp/tonclient8948088420223915752.so
> UnsatisfiedLinkError: /tmp/tonclient8948088420223915752.so: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /tmp/tonclient8948088420223915752.so)
io.tonlabs.client.Wrapper.getMessage()Ljava/lang/String;
java.lang.UnsatisfiedLinkError: io.tonlabs.client.Wrapper.getMessage()Ljava/lang/String;
	at io.tonlabs.client.Wrapper.getMessage(Native Method)
        ...

The same with ldd:

$ ldd ../library/src/main/resources/tonclient.so
../library/src/main/resources/tonclient.so: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by ../library/src/main/resources/tonclient.so)
        linux-vdso.so.1 =>  (0x00007ffffcfb5000)
        libssl.so.1.1 => not found
        libcrypto.so.1.1 => not found
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fab5cea2000)
        librt.so.1 => /lib64/librt.so.1 (0x00007fab5cc9a000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fab5ca7e000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fab5c868000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fab5c49a000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fab5e148000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fab5c198000)
        libz.so.1 => /lib64/libz.so.1 (0x00007fab5bf82000)

yum install openssl11-libs installed libssl.so.1.1 & libcrypto.so.1.1 - but yum info glibc says it 2.17.

The only way seems to install CentOS 8 or Debian, which have kernels built with later versions.


I might try the same on Windows 10 later, to see if it links the DLL.
Might building from source on CentOS 7 with glibc 2.17 work?

When building the Linux library with an alpine image, muslc might be an alternative to glibc.

Fetch first block failed: (certificate has expired)

"call_set":{"function_name":"submitTransaction","

### error:
{"code":504,"message":"Fetch first block failed: Can not send http request: error sending request for url (https://main4.ton.dev/graphql?query=%7Binfo%7Bversion%20time%7D%7D): error trying to connect: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264: (certificate has expired)","data":{"message_id":"b6c4d1a65d5f7ebce27983eaee44437c1b63f6bdd4667ef74252a05c311b9b86","core_version":"1.23.0","config_servers":["main2.ton.dev","main3.ton.dev","main4.ton.dev"]}} type=1 finished=false

Cell Encoding

Status: Approved

Problem

In some cases users want to build raw cells (BOCs) using low level TON primitives to pass them to contracts to decode them in contracts. Current client library hasn't such functions.

Solution

Provide feature for cell building:

  • boc.encode_builder – builds cell using builder write sequence.

Encode Builder String

/// Builder write commands.
enum BuilderWrite {
    /// Writes integer.
    Integer {
        /// Bit size of the value.
        size: u8,
        /// Value:
        /// - `Number` containing integer number. e.g. `123`, `-123`.
        /// - Decimal string. e.g. `"123"`, `"-123"`.
        /// - `0x` prefixed hexadecimal string.
        ///   e.g `0x123`, `0X123`, `-0x123`.
        /// If 
        value: Value
    },
    /// Writes bit string.
    BitString {
        /// Bit size. If `size` is zero than `buffer` contains 
        /// taged bit string.
        size: u16,
        // Buffer contained bit string content.
        // Bits layed out inside buffer in the big endian order.
        // So the first written bit is the least significant 
        // bit of the buffer[0].
        buffer: String,
    },
    /// Writes ref to nested cell
    Cell {
        /// Writes cell content
        write: Vec<BuilderWrite>,
    }
}

struct ParamsOfEncodeBuilder {
    write: Vec<BuilderWrite>,
    boc_cache: BocCacheType,
}

struct ResultOfEncodeBuilderString {
    boc: String,
}

// boc module
fn encode_builder(
    context,
    params: ParamsOfEncodeBuilder,
) -> ClientResult<ResultOfEncodeBuilder> {}

Wrapper library must defines helper constructors for write commands:

b0, b1, bit(true | false)
uint(size, value), u2(value)..u256(value)
int(size, value), i2(value)..i256(value)
bits(buffer, size?), utf8(text)

JS Example:

const boc = (await client.boc.encode_boc({
    write: [
        u8(12), i32(12345),
        u256(0x478321746387264738674623746372864783267812),
        b1(), cell([u8(13)]),
    ]
})).boc;

Compilation error

Fails to compile as a step of compilation of main.ton.dev

 Compiling ton_sdk v0.1.0 (https://github.com/tonlabs/TON-SDK.git#4f27347c)
error[E0599]: no associated item named `MAX` found for type `u64` in the current scope
   --> /home/ton/.cargo/git/checkouts/ton-sdk-11823a0ea1fdf592/4f27347/ton_sdk/src/transaction.rs:237:53
    |
237 |         fees.total_output = if total_output <= u64::MAX as u128 { total_output as u64 } else { 0 };
    |                                                     ^^^ associated item not found in `u64`
    |
    = help: items from traits can only be used if the trait is in scope
    = note: the following trait is implemented but not in scope; perhaps add a `use` for it:
            `use rand::distributions::weighted::alias_method::Weight;`
help: you are looking for the module in `std`, not the primitive type
    |
237 |         fees.total_output = if total_output <= std::u64::MAX as u128 { total_output as u64 } else { 0 };
    |                                                ^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0599`.
error: could not compile `ton_sdk`.
warning: build failed, waiting for other jobs to finish...
error: build failed

Rust: error: failed to select a version for `zeroize`

Outdated cryptography libraries in indirect dependencies appear to be causing conflicts with well-known libraries like sqlx.

error: failed to select a version for `zeroize`.
    ... required by package `rsa v0.9.0`
    ... which satisfies dependency `rsa = "^0.9"` of package `sqlx-mysql v0.7.0`
    ... which satisfies dependency `sqlx-mysql = "=0.7.0"` of package `sqlx v0.7.0`
    ... which satisfies dependency `sqlx = "^0.7"` of package `gosh-cache v0.0.0 (/Users/aw/pro/gosh/gosh-cache)`
versions that meet the requirements `^1.5` are: 1.6.0, 1.5.7, 1.5.6, 1.5.5, 1.5.4, 1.5.3

all possible versions conflict with previously selected packages.

  previously selected package `zeroize v1.3.0`
    ... which satisfies dependency `zeroize = "=1.3"` of package `x25519-dalek v1.2.0`
    ... which satisfies dependency `x25519-dalek = "^1.2"` of package `ton_types v2.0.15 (https://github.com/tonlabs/ever-types.git?tag=2.0.15#46601268)`
    ... which satisfies git dependency `ton_types` of package `ever-struct v0.1.2 (https://github.com/tonlabs/ever-struct.git?tag=0.1.2#4d03ee97)`
    ... which satisfies git dependency `ever-struct` of package `ton_client v1.44.1 (https://github.com/tonlabs/ever-sdk.git?tag=1.44.1#4cdee234)`
    ... which satisfies git dependency `ton_client` of package `gosh-cache v0.0.0 (/Users/aw/pro/gosh/gosh-cache)`

failed to select a version for `zeroize` which could resolve this conflict

Minimal steps to reproduce:

mkdir -p /tmp/test
cd /tmp/test
cargo init
cargo add sqlx
cargo add --git https://github.com/tonlabs/ever-sdk.git ton_client # >> Error

E.g. Cargo.toml

...
[dependencies]
sqlx = { version = "0.7" }
ton_client = { git = 'https://github.com/tonlabs/ever-sdk.git', tag = '1.44.1' }
...

Memory leak inside context

Hello dear team. You have a memory leak inside the ServerLink class initializer. Please fix this as there are large memory leaks every time a context is created. If you do not pass an array of endpoints when initializing the context, there is no memory leak.

Presumably the leak occurs in this section of code:

Снимок экрана 2023-06-22 в 15 07 04

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.