Hot answers tagged

17

You could modify Conseil in order to support the extraction of voting related info. Another approach is to use the tzscan codebase, which also fills a database with information from the Tezos node. Last but not least, you can use RPC calls to /chains/main/blocks/head/context/raw/json/.. to explore the raw context for every block.


14

Unfortunately there is no way to directly query just the delegator's reward from TzScan API. But you can easily use this API call with some extra calculations: //This is what the baker got var total_reward = rewards + extra_rewards - losses; //This is the delegator's share in the staking balance var share = balance / staking_balance; //This is the ...


11

<block_id> - is a hash or a level of the block at which you ask for balance. If you want to get a simple balance at the specific point in the cycle: (this is pseudocode, I hope you figure it out) var cycle = 60; var p1 = (cycle * 4096 + 1) + 0; //beginning of the cycle var p2 = (cycle * 4096 + 1) + 4095; //end of the cycle var balance_at_p1 = get('...


10

What we do for TezRPC (which powers TezBox) is run a proxy on each server. Within this proxy, you can then block, restrict and customize public facing endpoints. We currently use a light proxy built with NodeJS, but will switch over to a nginx style proxy (better performance). Here is an example of a node.js proxy that blocks almost all endpoints (...


9

You need to start the node with these options: --cors-header='content-type' --cors-origin='*'. Once you’ve started the node with these options the response headers should allow a JavaScript application to make RPC calls to a Tezos node.


9

If you are using a configuration file, there are two different ports : the "listen-addr" option can be used both in the "p2p" section and in the "rpc" section. You can use "0.0.0.0:8732" for example to listen on port 8732 on all addresses. You can also use the command line: tezos-node run --rpc-addr 0.0.0.0:8732


8

You can use TzScan API for this: /v3/balance_history/KT1..., the documentation is here: balance history doc. For example https://api6.tzscan.io/v3/balance_history/KT1GgUJwMQoFayRYNwamRAYCvHBLzgorLoGo


8

There are multiple references online which provide material to understand the steps involved in this. You can check this or that. Some elements are also provided in this other question Basically the steps are get dependencies branch hash: /chains/main/blocks/head/hash counter: /chains/main/blocks/head/context/contracts/<source_pkh>/counter protocol ...


8

The new CLI and RPC for big map expect hash of a script expression, instead of the raw expression. To obtain the hash you can e.g.: tezos-client hash data '"tz1bwsEWCwSEXdRvnJxvegQZKeX5dj6oKEys"' of type address This will print hashes in bunch of different formats - you want the one with the label Script-expression-ID-Hash, e.g. ...


7

$ ./tezos-client rpc schema post /chains/main/blocks/head/helpers/forge/operations | jq '.input.definitions."operation.alpha.contents".oneOf | .[] | .properties.kind.enum | .[0]' "endorsement" "seed_nonce_revelation" "double_endorsement_evidence" "double_baking_evidence" "activate_account" "proposals" "ballot" "reveal" "transaction" "origination" "delegation"...


7

Either: don't expose the RPC at all (!), or put a proxy in front with a maximally restrictive whitelist. Of course, for a whitelist to help, you must not include potentially harmful endpoints in your whitelist... Even seemingly harmless endpoints might be used for denial of service, and some endpoints are surprisingly harmful.


7

GET ../<block_id>/helpers/baking_rights?(level=<block_level>)*&(cycle=<block_cycle>)*&(delegate=<pkh>)*&[max_priority=<int>]&[all] Retrieves the list of delegates allowed to bake a block. By default, it gives the best baking priorities for bakers that have at least one opportunity below the 64th priority ...


7

A node does not keep the former alternative heads. You can only query the current heads: tezos-client -A mainnet-node.tzscan.io rpc help /chains/main/blocks Old ones are removed when their fitness is too small compared to new ones. You can see them on TzScan, but only the ones that TzScan saw (your node might see other ones), because TzScan stores them in ...


6

When you only need the RPC for yourself you could also use ssh local port forwarding to forward the RPC from the localhost of your remote machine to the localhost of your local machine. For instance, as a background process: ssh -fNT -L 8732:localhost:8732 user@hostname I don't know how safe this is though.


6

One of the alternatives i could think of, is using Conseil: https://github.com/Cryptonomic/Conseil In my humble understanding what Conseil does, is provide an extended API on top of a tezos-node/rpc. And perhaps (?) some extra features which could allow enabling/disabling endpoints or other security measures. Here's a few examples


6

You are sending your query to the wrong address - it should be (note you are missing "chain/main/"): https://alphanet-node.tzscan.io/chains/main/blocks/head/context/contracts/<contract_id>/big_map_get I recommend using the https version too. I have successfully queried this endpoint with a smart contract of my own and verified the response: eztz....


5

The problem is that /parse/operations expects signed operations. You can just add 64 zero bytes to the end: { "operations": [ { "data": "...


5

This is currently not supported. You can use an nginx proxy to secure it with HTTP Basic Authentication with the following configuration that uses a https connection on standard port: server { listen 443 ssl; server_name tezosz-rpc.yourdomain.com; include letsencrypt_ssl.conf; ssl_certificate /fullchain.cer; ssl_certificate_key /tezosz-rpc....


5

The chain_id is computed from the genesis block hash as follows. First, in pseudocode: tezosB58CheckEncode('Net', firstFourBytes( blake2b(msg = tezosB58CheckDecode('B', genesisBlockHash), size = 32))) In detail: Take the genesis block hash. For example, in mainnet, this is "BLockGenesisGenesisGenesisGenesisGenesisf79b5d1CoW2". ...


5

The cli command is tezos-client get big map value for <key> of type <type of the key> in <contract>. By adding the -l option, we also get the RPC: /chains/main/blocks/head/context/contracts/<contract address>/big_map_get. Actually, you do not need to know the big map index, if several big_maps with the same type of keys are stored, ...


4

You can use the contract send method: eztz.contract.send(contract, keys, amount, parameter, fee, gasLimit, storageLimit) For parameter, you just enter in the raw Michelson input (the same you would use via the tezos-client command). e.g. You could do: eztz.contract.send(contract, keys, amount, '(Left (Pair "test" 1))', fee, gasLimit, storageLimit) //For ...


4

helpers/scripts/run_operation is useful to simulate an operation without signing it (you may use zero bytes for the signature), in order to estimate the gas and storage requirements. You will see tezos-client -l setting gas_limit and storage_limit to the maximum values here, and then using the result to set the actual gas_limit and storage_limit (subject to ...


4

You cannot exceed the hard_gas_limit_per_operation = 400000. It will probably be increased in future protocols, though (see e.g. the "Athens" proposals). Internal transfers can use up a lot of gas. First, there is a fixed cost of 10000 gas per transfer. Second, and more importantly, when a contract is 'parsed', the contract's entire code and storage are ...


4

No it is not. Constants are set in the genesis block and then changed only by amendments. They are stored in the context, which is the state passed to and returned by the protocol when it validates a block. That's why the RPC requires a block and inspects its context to read the constants.


4

You can get information about snapshot for a given cycle from the raw context: var cycle = 100; var level = cycle * 4096 + 1; var snapshot = get('/chains/main/blocks/{level}/context/raw/json/cycle/{cycle}/roll_snapshot'); var snapshot_block = ((cycle - 7) * 4096 + 1) + (snapshot + 1) * 256 - 1; var balance = get('/chains/main/blocks/{snapshot_block}/...


4

As of 004_Pt24m4xi: You can use the big_map_get RPC to get individual values out. There is also a tezos-client command for this. (By passing -l we can see how it works through the RPC.) $ tezos-client -l get big map value for 1 of type nat in KT1Qu32f8N5RLPoku5n8itiGaJ1a3eJDj5gu ... >>>>2: http://localhost:18731/chains/main/blocks/head/context/...


4

You can request the current head of your node using ./tezos-client rpc get /chains/main/blocks/head (and look for the level and hash information). Then, use your favorite block explorer to know the level of the current head. Alternatively, the ./tezos-client bootstrapped command aims to hang and return only when the node is synchronized.


4

The tezos-client and tezos-node RPC have no such feature. If you don't mind using an API other then the node RPC you can find this in the new version of the tzstats indexer (GET /explorer/contract/{hash} returns an object with a key bigmap_ids which is an array) see https://api.babylonnet.tzstats.com/explorer/contract/KT1E5toJrALhVPuKpHWTbRVjgEvWWR98sVKj ...


4

You can use the HTTP-RPC interface on your local node. http://localhost:8732/chains/main/blocks/{BLOCK}/context/contracts/{ADDRESS}/balance On a default node, this is only good for the previous 5 cycles. If you want balances older than that, you need to use an archive node. Other options are to use the API provided by most block explorers like tzstats.com ...


3

First you have to find out which snapshot was used for cycle X. Use (cycle# * blocksPerCycle + 1) to get the hash of the first block of that cycle. Then you can query: "/chains/main/blocks/"+blockHash+"/context/raw/json/cycle/"+cycle# This gets you information about the snapshots for this cycle. From this info, grab the RollSnapShot value. This tells you ...


Only top voted, non community-wiki answers of a minimum length are eligible