I am one of the developer working on the integration of some privacy features based on ZKP at Tezos.
Yes there are many tradeoffs in ZKP.
I can try to sum up some them and explain our choices.
The first is interactive vs non interactive (ie. the prover and verifier exchange several messages).
In a blockchain context since people can go on and offline, non ...
The first list contains the endorsements.
The second list contains all the operations regarding votes and proposals.
The third list contains anonymous operations.
The last one contains the manager operations (reveal, transaction, delegation and origination).
If you need to check only the transactions, you should check only the last one.
TzScan has a service for that, but only for the current value:
Fundamentally a cycle is a set of block heights for which the baking en endorsement rights are determined by a single random seed.
The reason to have many blocks in a cycle is that it lowers the incentive to try and manipulate the random seed (since most seeds will produce similar distributions on average). The reason not to have too many blocks in a cycle ...
In principle the node doesn't need to be updated, it is capable of receiving a new protocol 004, compile it and use it to validate blocks produced by protocol 004. In practice it is a good idea to update to the latest release because there are always useful improvements. For example the snapshots introduced in Mainnet May allow for a much faster validation ...
If what you mean is a non-predictable source of randomness, no, there is none. Any information that could be used for that could either be predictable by a user, or tempered by a malicious baker.
You should probably use an external source of randomness, as the oracle presented in here.
An improvement of that would be to use commitments, i.e. the oracle ...
The information is available from the official documentation in the « Baker » section
The basic formula specifies that fees are now dependent on 3 parameters: a fixed minimum fee, a fee by storage unit and a fee by gas unit (reflection the cost of performing calculations). Those 3 parameters are ...
In Tezos, the fee is independant from the gas : whatever the gas consumed, you always pay the full fee.
However, bakers will probably compute the ratio fee/gas, and prefer transactions with higher fee/gas, i.e. more reward for less computation.
Implicit (tz* accounts) can be removed by storage by reducing the balance to 0, and ensuring the account isn't a registered delegate. If the account is registered, there's no direct way to de-register, you just need to wait for the grace period to end. Do note, additional gas (and therefore fees) are required to empty and remove an implicit account from ...
Currently 1 tez (1 XTZ) is divisible to six decimal places, and the smallest unit is called a micro tez.
1 tez = 1,000,000 micro tez
In code it is referred to as mutez and it is defined in src/proto_alpha/lib_protocol/qty_repr.ml (circa line 94):
let one_mutez = 1L
let one_cent = Int64.mul one_mutez 10_000L
let fifty_cents = Int64.mul one_cent 50L
In Tezos Alpha the Transaction List size is limited:
Tezos does not download blocks all at once, but rather considers headers and various lists of operations separately. In Tezos.alpha, a maximum size in bytes is applied to the list of transactions MAX_TRANSACTION_LIST_SIZE = 500kB (that’s 5MB every 10 minutes at most).
Other lists of operations (...
Fundamentally, nonces are used by the blockchain to create randomness, such as choosing the snapshot for a cycle. Nonces are created by bakers and all the nonces for the cycle are combined to create a random seed. When baking blocks, you may be required to reveal a nonce in the next cycle. This nonce requirement is determinstic and happens every 32 blocks. ...
We will need these operations:
blake2b: size 32
concat: concatenation of byte arrays
Also, let zero_bytes be 32 zero bytes.
My answer is based on seed_storage.ml and seed_repr.ml, with some experimentation.
Let's start at the beginning.
The initial preserved_cycles+2 = 7 seeds were determined ahead of time, as follows. The first seed is ...
The P2P layer is part of the shell and is not amended via the onchain governance. Improvements to the existing approach are always welcome by contributing to the gitlab.
People are also free to work on separate implementations of the shell and explore different approaches to optimization while still remaining compatible with the existing shell. And of ...
Take blake2b hash of arbitrary data.
Prepend \x02\xaa and base58 encode it with checksum.
Example in Python:
from pytezos.encoding import base58_encode
from pytezos.crypto import blake2b_32
1) About the ed25519 public key, and how it is in bytes:
Ed25519 keys start life as a 32-byte (256-bit) uniformly random binary seed (e.g. the output of SHA256 on some random input). The seed is then hashed using SHA512, which gets you 64 bytes (512 bits), which is then split into a “left half” (the first 32 bytes) and a “right half”. The left ...
The current protocol does not keep track of a tally of all tez on the network. It would be a good idea to do so, as it permits computing proportional reward, it can serve as a canari against money printing bugs, and it can be used to refine the governance model.
Since the protocol doesn't keep track of it, there's no node RPC that will give you that ...
This happened directly as part of the context "stitching". When a new protocol is activated, an initialization function is called which lets the new protocol performs some housekeeping on the context to make it compatible with the new code base. This can include changing some of the data structures involved in representing the ledger (e.g. roll base) but, in ...
What happen at the network level is the combination of 2 phenomenons:
First and foremost, we can expect that bakers (who voted for this amended protocol!) will run up to date software and therefore produce blocks in protocol PsBabyM1 so very few blocks in protocol PsBABY5Hwill ever be produced.
Second, even if there is people with baking rights who produce ...
"Stakeholders govern the protocol" is what it says, there is on-chain governance process where amendments to protocol are voted by stakeholders. An overview of how it is done can be found here.
It is a 3 step process. In first step filters out best proposals among many via stakeholder voting. In second step, a vote decides inclusion of protocol in test ...
The full fee is always paid for every transactions - the gas limit is just that, a cap on the amount of gas a given transaction can consume. A baker can be guaranteed that they are paid at least fee/gas_limit per unit of gas consumed, even if they consume less.
Some bakers will also enforce a minimum per_gas fee, which is currently set to 0.1 mutez (or 1 ...
Difference between reveal and transaction:
When a wallet sends a transaction, it must sign the transaction with the user's private key. However, there is no way for other users to check the signature, if they don't have the corresponding public key. That's why the wallet must issue a Reveal operation first, to reveal the public key of the user.
Your magicbyte seems to be wrong. If you take the decimal byte values from the original, convert them to hex, then pad it with a leading zero, you get
>>> struct.unpack('>L', b'\x00\x57\x52\x00')
This value should produce the expected result:
>>> payload = '...
Bakers don’t have to update the node when athens goes through. The updated rules will activate automagically at the end of the voting cycle (if succesful).
For the baking deamons updated software needs to be run in general since an amendment can have direct impact on the construction of the new block.
From an operational persective i believe that you ...
The Exploration phase for Pt24m4xi.....(Athens A) will end on block level 39216.
We have a supermajority to test the winning proposal (Athens A)
This means that when the exploration phase (https://tzscan.io/proposals) ends the Tezos chain is forked with a test chain and the 004-Pt24m4xi binaries must be used on this test chain. The main chain still remains ...
1. No, it's not correct.
There are two types of operations in Tezos: ordinary and internal (aka a result of smart contracts execution). If there is a nonce field or originalSender field, then it's an internal operation.
In case of internal operation, original sender pays for all the fees, so here is the correct code:
if (tx.originalSender != null)
Docs in tezos.git
Docs by TezTech
To copy from the tezos.git docs:
fees >= (minimal_fees + minimal_nanotez_per_byte * size
+ minimal_nanotez_per_gas_unit * gas)
(size is the size of the operation in binary.)
With current defaults:
minimal_fees = 0.000 1 ꜩ (100 µꜩ)
minimal_nanotez_per_gas_unit = 100 nꜩ/gu (0.000 000 1 ꜩ/gu)
It looks like you are only actually grabbing 2 bytes of data (4 hex chars). I verified this by decoding the result you got, and it only returning two bytes of data for the given magic byte.
Try making the following change:
chainid = bytes.fromhex(self.payload[2:10])
return bitcoin.bin_to_b58check(chainid, magicbyte=5722583)
A "Tezos protocol hash" like PsqEZzKWvmWY29kV6oJZhWDNz9FMmYDjV3S7c496zMuAGDYAF7e is the Base58Check encoding of the hash of some protocol code.
The Base58Check encoding of some data is obtained as follows:
base58encode(prefix + data + checksum)
where prefix is some fixed bytestring used to identify the type of data we are encoding, data is the ...