Type Members

1.  case class Block(parentId: ModifierId, timestamp: Time, generatorBox: ArbitBox, publicKey: PublicKeyPropositionCurve25519, signature: SignatureCurve25519, height: Long, difficulty: Long, transactions: Seq[TX], version: PNVMVersion) extends TransactionCarryingPersistentNodeViewModifier[TX] with Product with Serializable

   A block is an atomic piece of data network participates are agreed on.

   A block is an atomic piece of data network participates are agreed on.

   A block has: - transactional data: a sequence of transactions, where a transaction is an atomic state update. Some metadata is possible as well(transactions Merkle tree root, state Merkle tree root etc).

   - consensus data to check whether block was generated by a right party in a right way. E.g. "baseTarget" & "generatorSignature" fields in the Nxt block structure, nonce & difficulty in the Bitcoin block structure.

   - a signature(s) of a block generator(s)

   - additional data: block structure version no, timestamp etc

2.  case class BlockBody(id: ModifierId, parentId: ModifierId, transactions: Seq[TX], version: PNVMVersion) extends TransactionCarryingPersistentNodeViewModifier[TX] with Product with Serializable
3.  case class BlockHeader(id: ModifierId, parentId: ModifierId, timestamp: Time, generatorBox: ArbitBox, publicKey: PublicKeyPropositionCurve25519, signature: SignatureCurve25519, height: Long, difficulty: Long, txRoot: Digest32, bloomFilter: BloomFilter, version: PNVMVersion) extends PersistentNodeViewModifier with Product with Serializable
4.  class BloomFilter extends BytesSerializable

   This implementation of Bloom filter is inspired from the Ethereum Yellow Paper for more information, visit: http://gavwood.com/paper.pdf (as of 2020.11.20 there is an error in footnote 3 - 2¹¹ = 2048) Another explanation can be found here (but he messes denoting the byte pairs, this stuff is tricky) https://ethereum.stackexchange.com/questions/59203/what-exactly-does-the-m-function-in-the-formal-bloom-filter-specifications-do A calculator to look at the false positivity rate can be found here https://hur.st/bloomfilter/?n=100&p=&m=2048&k=4 The bloom filter is constructed by taking the low-order 11 bits (mod 2048) of each of the first four pairs of bytes from a Blake2b-256 hash In english, the algorithm is to hash the input topic, take the first 8 bytes from the hash output, pair them up (1,2) (3,4) (5,6) (7,8), then take the first 11 bits from each pair (each pair is 16 bits and we take 11 bits because 2¹¹ = 2048).

   This implementation of Bloom filter is inspired from the Ethereum Yellow Paper for more information, visit: http://gavwood.com/paper.pdf (as of 2020.11.20 there is an error in footnote 3 - 2¹¹ = 2048) Another explanation can be found here (but he messes denoting the byte pairs, this stuff is tricky) https://ethereum.stackexchange.com/questions/59203/what-exactly-does-the-m-function-in-the-formal-bloom-filter-specifications-do A calculator to look at the false positivity rate can be found here https://hur.st/bloomfilter/?n=100&p=&m=2048&k=4 The bloom filter is constructed by taking the low-order 11 bits (mod 2048) of each of the first four pairs of bytes from a Blake2b-256 hash In english, the algorithm is to hash the input topic, take the first 8 bytes from the hash output, pair them up (1,2) (3,4) (5,6) (7,8), then take the first 11 bits from each pair (each pair is 16 bits and we take 11 bits because 2¹¹ = 2048). These bits can be retrieved using a bit-wise AND operation. For each of the 11-bit numbers we construct a positive definite integer between (0 & 2047). This integer is the index of the bit to flip in the bloom filter. Finally, the bloom filter is represented as a Array[Long] so we must apply two additional bit-wise AND operations on each index to find which Long should be changed in the bloom filter and finally which bit of the Long must be flipped.

5.  trait PersistentNodeViewModifier extends NodeViewModifier
6.  trait TransactionCarryingPersistentNodeViewModifier[TX <: TX] extends PersistentNodeViewModifier