everscale-client-ruby 1.1.25 → 1.1.27

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 158aeb32c2b00284f9e6b1020b4f5eea3c48a3749c058c04aa06a89ed57172d2
-  data.tar.gz: 10197b9bfaae08cda1555db0837cbfca2b126a7bb530556c821bdca2df08f486
+  metadata.gz: 381333ce163f494aadd05eaf56926606ed84543213236e617082111365e745e3
+  data.tar.gz: e3f6c603dad3994f66a6c15141ac23607b07e57b4de801209408c5ac8451e83e
 SHA512:
-  metadata.gz: a880fbff049be8ef712b6ef936f75daff9d3f01bea6941df2a2efdc8968d0d38682539509ced93db7707564b21d3cc34161dde4dd97351eca599d90d3b82d0e6
-  data.tar.gz: 73ff2c654aae026a73176b7269faec9ea66dfdc971c62c53a80a697d993c2be463acdf24546c442d4e0c359559492fb45094845d59c22bf2ea29724be28675be
+  metadata.gz: ff96b32175217aceb73bb994913cef1e36d99047589f495ac0e190be8b1e408331b8cb6b5cfb110512af675a797f3eb9433908fc56ea0aa3e437eca6ac304e2f
+  data.tar.gz: d5a3149cf6670f078c6e24506ee6bf3d8c84c06ff25fa1119fbc9f2cc9bee700600cf5845b6fb546d743defe62e80b43f0ff684f98a9327c4838db2e00ec74cc

data/lib/code_generator/api.json

@@ -365,7 +365,7 @@
               "optional_inner": {
                 "type": "String"
               },
-              "summary": "DApp Server public address. For instance, for `net.ton.dev/graphql` GraphQL endpoint the server address will be net.ton.dev",
+              "summary": "**This field is deprecated, but left for backward-compatibility.** DApp Server public address.",
               "description": null
             },
             {
@@ -378,7 +378,7 @@
                 }
               },
               "summary": "List of DApp Server addresses.",
-              "description": "Any correct URL format can be specified, including IP addresses This parameter is prevailing over `server_address`."
+              "description": "Any correct URL format can be specified, including IP addresses. This parameter is prevailing over `server_address`.\nCheck the full list of [supported network endpoints](../ton-os-api/networks.md)."
             },
             {
               "name": "network_retries_count",
@@ -12421,7 +12421,7 @@
         {
           "name": "query_counterparties",
           "summary": "Allows to query and paginate through the list of accounts that the specified account has interacted with, sorted by the time of the last internal message between accounts",
-          "description": "*Attention* this query retrieves data from 'Counterparties' service which is not supported in\nthe opensource version of DApp Server (and will not be supported) as well as in TON OS SE (will be supported in SE in future),\nbut is always accessible via [TON OS Devnet/Mainnet Clouds](https://docs.ton.dev/86757ecb2/p/85c869-networks)",
+          "description": "*Attention* this query retrieves data from 'Counterparties' service which is not supported in\nthe opensource version of DApp Server (and will not be supported) as well as in Evernode SE (will be supported in SE in future),\nbut is always accessible via [EVER OS Clouds](../ton-os-api/networks.md)",
           "params": [
             {
               "name": "context",
@@ -13753,7 +13753,7 @@
         {
           "name": "proof_block_data",
           "summary": "Proves that a given block's data, which is queried from TONOS API, can be trusted.",
-          "description": "This function checks block proofs and compares given data with the proven.\nIf the given data differs from the proven, the exception will be thrown.\nThe input param is a single block's JSON object, which was queried from DApp server using\nfunctions such as `net.query`, `net.query_collection` or `net.wait_for_collection`.\nIf block's BOC is not provided in the JSON, it will be queried from DApp server\n(in this case it is required to provide at least `id` of block).\n\nPlease note, that joins (like `signatures` in `Block`) are separated entities and not supported,\nso function will throw an exception in a case if JSON being checked has such entities in it.\n\nIf `cache_in_local_storage` in config is set to `true` (default), downloaded proofs and\nmaster-chain BOCs are saved into the persistent local storage (e.g. file system for native\nenvironments or browser's IndexedDB for the web); otherwise all the data is cached only in\nmemory in current client's context and will be lost after destruction of the client.\n\n**Why Proofs are needed**\n\nProofs are needed to ensure that the data downloaded from a DApp server is real blockchain\ndata. Checking proofs can protect from the malicious DApp server which can potentially provide\nfake data, or also from \"Man in the Middle\" attacks class.\n\n**What Proofs are**\n\nSimply, proof is a list of signatures of validators', which have signed this particular master-\nblock.\n\nThe very first validator set's public keys are included in the zero-state. Whe know a root hash\nof the zero-state, because it is stored in the network configuration file, it is our authority\nroot. For proving zero-state it is enough to calculate and compare its root hash.\n\nIn each new validator cycle the validator set is changed. The new one is stored in a key-block,\nwhich is signed by the validator set, which we already trust, the next validator set will be\nstored to the new key-block and signed by the current validator set, and so on.\n\nIn order to prove any block in the master-chain we need to check, that it has been signed by\na trusted validator set. So we need to check all key-blocks' proofs, started from the zero-state\nand until the block, which we want to prove. But it can take a lot of time and traffic to\ndownload and prove all key-blocks on a client. For solving this, special trusted blocks are used\nin TON-SDK.\n\nThe trusted block is the authority root, as well, as the zero-state. Each trusted block is the\n`id` (e.g. `root_hash`) of the already proven key-block. There can be plenty of trusted\nblocks, so there can be a lot of authority roots. The hashes of trusted blocks for MainNet\nand DevNet are hardcoded in SDK in a separated binary file (trusted_key_blocks.bin) and is\nbeing updated for each release by using `update_trusted_blocks` utility.\n\nSee [update_trusted_blocks](../../../tools/update_trusted_blocks) directory for more info.\n\nIn future SDK releases, one will also be able to provide their hashes of trusted blocks for\nother networks, besides for MainNet and DevNet.\nBy using trusted key-blocks, in order to prove any block, we can prove chain of key-blocks to\nthe closest previous trusted key-block, not only to the zero-state.\n\nBut shard-blocks don't have proofs on DApp server. In this case, in order to prove any shard-\nblock data, we search for a corresponding master-block, which contains the root hash of this\nshard-block, or some shard block which is linked to that block in shard-chain. After proving\nthis master-block, we traverse through each link and calculate and compare hashes with links,\none-by-one. After that we can ensure that this shard-block has also been proven.",
+          "description": "This function checks block proofs and compares given data with the proven.\nIf the given data differs from the proven, the exception will be thrown.\nThe input param is a single block's JSON object, which was queried from DApp server using\nfunctions such as `net.query`, `net.query_collection` or `net.wait_for_collection`.\nIf block's BOC is not provided in the JSON, it will be queried from DApp server\n(in this case it is required to provide at least `id` of block).\n\nPlease note, that joins (like `signatures` in `Block`) are separated entities and not supported,\nso function will throw an exception in a case if JSON being checked has such entities in it.\n\nIf `cache_in_local_storage` in config is set to `true` (default), downloaded proofs and\nmaster-chain BOCs are saved into the persistent local storage (e.g. file system for native\nenvironments or browser's IndexedDB for the web); otherwise all the data is cached only in\nmemory in current client's context and will be lost after destruction of the client.\n\n**Why Proofs are needed**\n\nProofs are needed to ensure that the data downloaded from a DApp server is real blockchain\ndata. Checking proofs can protect from the malicious DApp server which can potentially provide\nfake data, or also from \"Man in the Middle\" attacks class.\n\n**What Proofs are**\n\nSimply, proof is a list of signatures of validators', which have signed this particular master-\nblock.\n\nThe very first validator set's public keys are included in the zero-state. Whe know a root hash\nof the zero-state, because it is stored in the network configuration file, it is our authority\nroot. For proving zero-state it is enough to calculate and compare its root hash.\n\nIn each new validator cycle the validator set is changed. The new one is stored in a key-block,\nwhich is signed by the validator set, which we already trust, the next validator set will be\nstored to the new key-block and signed by the current validator set, and so on.\n\nIn order to prove any block in the master-chain we need to check, that it has been signed by\na trusted validator set. So we need to check all key-blocks' proofs, started from the zero-state\nand until the block, which we want to prove. But it can take a lot of time and traffic to\ndownload and prove all key-blocks on a client. For solving this, special trusted blocks are used\nin Ever-SDK.\n\nThe trusted block is the authority root, as well, as the zero-state. Each trusted block is the\n`id` (e.g. `root_hash`) of the already proven key-block. There can be plenty of trusted\nblocks, so there can be a lot of authority roots. The hashes of trusted blocks for MainNet\nand DevNet are hardcoded in SDK in a separated binary file (trusted_key_blocks.bin) and is\nbeing updated for each release by using `update_trusted_blocks` utility.\n\nSee [update_trusted_blocks](../../../tools/update_trusted_blocks) directory for more info.\n\nIn future SDK releases, one will also be able to provide their hashes of trusted blocks for\nother networks, besides for MainNet and DevNet.\nBy using trusted key-blocks, in order to prove any block, we can prove chain of key-blocks to\nthe closest previous trusted key-block, not only to the zero-state.\n\nBut shard-blocks don't have proofs on DApp server. In this case, in order to prove any shard-\nblock data, we search for a corresponding master-block, which contains the root hash of this\nshard-block, or some shard block which is linked to that block in shard-chain. After proving\nthis master-block, we traverse through each link and calculate and compare hashes with links,\none-by-one. After that we can ensure that this shard-block has also been proven.",
           "params": [
             {
               "name": "context",

data/lib/everscale-client-ruby/version.rb

@@ -1,4 +1,4 @@
 module TonClient
-  VERSION = "1.1.25"
+  VERSION = "1.1.27"
 end
 

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: everscale-client-ruby
 version: !ruby/object:Gem::Version
-  version: 1.1.25
+  version: 1.1.27
 platform: ruby
 authors:
 - nerzh
 autorequire:
 bindir: bin
 cert_chain: []
-date: 2022-04-17 00:00:00.000000000 Z
+date: 2022-05-01 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: ffi
@@ -112,11 +112,11 @@ description: Gem Ton Client Ruby for all ruby projects
 email:
 - emptystamp@gmail.com
 executables:
-- ton-client-ruby
+- everscale-client-ruby
 extensions: []
 extra_rdoc_files: []
 files:
-- bin/ton-client-ruby
+- bin/everscale-client-ruby
 - lib/code_generator/api.json
 - lib/code_generator/api_converter.rb
 - lib/code_generator/code_generator.rb