Skip to content

Commit 7a04b88

Browse files
edutomescoedutomesco
authored
Merge pull request #3 from bloock/feature/EIT-3672
2 parents d78a1e5 + 23a6edb commit 7a04b88

26 files changed

+316
-221
lines changed

‎docs/guides/products/integrity/concepts/_category_.json‎

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
{
2+
"position": 2,
3+
"label": "Concepts",
4+
"collapsible": true
5+
}

‎docs/guides/products/integrity/concepts/anchor-entity.mdx‎

Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
---
2+
title: 'Anchor entity'
3+
sidebar_position: 4
4+
---
5+
6+
# The anchor entity
7+
8+
As described in the [Protocol Overview](./protocol.mdx#protocol-overview), we use a set of sparse Merkle trees that forms our Rollup. Once you send some data, it gets enqueued until we trigger the anchor mechanism.
9+
10+
This process consists in getting all the pending data and adding them to the state tree. This will produce a state transition and the resulting root will be transacted into several blockchain networks following the time intervals described in the [Networks supported](./networks-supported.mdx#networks-supported) section.
11+
12+
:::tip
13+
As a more formal definition: An anchor is a snapshot of the state tree which is registered to the blockchain protocol. It is formed by the resulting state of the state transition.
14+
:::
15+
16+
### Anchor identifier
17+
18+
We identify anchors with sequential numbers starting from 1. When you send a new data for certification, you will receive the anchor identifier in which your data will be processed, usually this is the next available one.
19+
20+
### Relation of anchors with blockchain networks
21+
22+
It's important to note that not all the anchors processed are transacted into all the blockchain networks supported by BLOOCK. This means that if you directly query some root of a random anchor into a network, it's possible (and common) that the result is not found.
23+
This is because we have different transaction intervals for the different networks supported. However, we do guarantee that every anchor gets transacted to at least one network.
24+
The integrity proof retrieval process manages this so you don't get an integrity proof that results in a root not transacted to the selected network.
25+
For a better understanding of this topic, here's a diagram of how anchors and transactions work together:
26+
27+
![5 - Integrity](/static/docs/guides/integrity/5-integrity.png)

‎docs/guides/products/integrity/concepts/integrity-proof-entity.mdx‎

Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,28 @@
1+
---
2+
title: 'Integrity proof entity'
3+
sidebar_position: 5
4+
---
5+
6+
# The integrity proof entity {#integrity-proof-entity}
7+
8+
Once a data submitted to BLOOCK for certification gets included in an anchor, you are able to retrieve an integrity proof for it.
9+
This proof is computed as an optimized Merkle proof by BLOOCK representing the minimal necessary data to mathematically prove that a record was included at a certain point in time to the blockchain. The computed proof has the following properties:
10+
Timeless, meaning that, once retrieved, those can be verified at any time in the future.
11+
12+
- Proofs can be retrieved for multiple records which enables to verify the existence of a set of records at once.
13+
- Proofs are auto verifiable by the user without the intervention of BLOOCK.
14+
15+
:::tip
16+
It's important to note that BLOOCK is not able to emit fraudulent proofs because of the cryptographic properties of the Merkle trees.
17+
:::
18+
19+
When you retrieve an integrity proof for one or more data to be able to further verify them, you will receive a set of data consisting of:
20+
21+
| Field | Description |
22+
| ------ | ------------------------------------------------------------------------------------------------------ |
23+
| Leaves | An array of hashes that contains exactly the input data to get the integrity proof from. |
24+
| Nodes | An array of hashes that will be combined with the leaves to run the Merkle proof verification process. |
25+
| Bitmap | Hexadecimal value used to combine the leaves and nodes in order to correctly compute the proof. |
26+
| Depth | Additional information needed to run the verification process. |
27+
| Root | The anchor root that the integrity proof should resolve to when verified. |
28+
| Anchor | Contains information related to the anchor from which the integrity proof was computed from. |

‎docs/guides/products/integrity/networks-supported.mdx‎ renamed to ‎docs/guides/products/integrity/concepts/networks-supported.mdx‎

Lines changed: 3 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,9 @@
11
---
22
title: 'Networks supported'
3-
sidebar_position: 3
3+
sidebar_position: 2
44
---
55

6-
# Networks supported
6+
# Networks supported {#networks-supported}
77

88
BLOOCK's protocol allows for interoperability between different blockchain networks, meaning that anchors processed by our system gets transacted in multiple chains so you are able to verify your data in any of them.
99

@@ -16,7 +16,7 @@ This allows for different benefits for our customers such as:
1616

1717
We transact to each network in different intervals. This is because of two reasons: the chain's block interval and the transaction cost.
1818

19-
## Live environment
19+
## Networks
2020

2121
Here is a list of blockchain we integrate with and the the approximate transaction intervals:
2222

@@ -46,13 +46,3 @@ Here is a list of blockchain we integrate with and the the approximate transacti
4646
</tr>
4747
</tbody>
4848
</table>
49-
50-
## Test environment
51-
52-
Our test environment is designed for development-only purposes, providing low transaction intervals to facilitate the development and integration with our SDKs.
53-
54-
To do so, anchors processed in that environment are only transacted into a private EVM-compatible blockchain managed by BLOOCK called BloockChain:
55-
56-
| Network | Contract address | Interval |
57-
| ----------- | ---------------------------------------- | ---------- |
58-
| BloockChain | d2d1BBcbee7741f8C846826F55b7c17fc5cf969a | \~1 minute |

‎docs/guides/products/integrity/protocol.mdx‎ renamed to ‎docs/guides/products/integrity/concepts/protocol.mdx‎

Lines changed: 6 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,16 +1,18 @@
11
---
22
title: 'Protocol'
3-
sidebar_position: 2
3+
sidebar_position: 1
44
---
55

6-
# Overview
6+
# Overview {#protocol-overview}
77

88
This is an overview of the BLOOCK's Protocol and its technological stack. It's objective is to provide an introduction for developers to BLOOCK's technical stack. It also offers the approach to achieve high scalability. The explanation assumes you are familiar with the Ethereum ecosystem, the basic concepts of cryptography, and structures such as hashing and Merkle trees.
99

1010
## First approach
1111

1212
BLOOCK is a rollup solution that allows scaling data-tamper proofing on top of permissionless blockchain technologies. It uses blockchains for state storage but not for the computation of the aggregations, which is made internally with a specific frequency that depends on the network it is anchored to. The basic architecture of BLOOCK is simplified to ease understanding:
1313

14+
![3 - Integrity](/static/docs/guides/integrity/3-integrity.png)
15+
1416
## Protocol
1517

1618
BLOOCK manages an internal protocol that aggregates and consolidates messages to the L2 rollup with a certain time frequency. The messages received are queued internally between anchors in a pool of pending certificates. When the anchoring mechanism is executed, all the pending messages of the pool are included in the state chain of each client. A state chain is client independent and each client owns its chain of states. A genesis random hash forms the first block of each client state chain along with a set of certifications sent since the last confirmed anchor. From there on, the last client block root represents each block and all the certifications sent since the last confirmed anchor. Some may be wondering why is it necessary to separate each client message into independent shards. Mainly because of the following crucial points:
@@ -20,3 +22,5 @@ BLOOCK manages an internal protocol that aggregates and consolidates messages to
2022
- _**Right to be forgotten:**_ Any client in need to remove all certifications from BLOOCK State will be allowed to do so. BLOOCK will just keep the root of each of its blocks in the Rollup, which indeed has 0 links to the certifications sent thanks to the first block genesis hash.
2123

2224
Once all client messages have been included in their respective state chains, the root of each new block created is appended to the BLOOCK Rollup stored by an only-append binary sparse Merkle tree. Once this action is finalized, we can conclude that all pending messages have been incorporated into the state of BLOOCK. Since we have a single shared state tree, BLOOCK can provide proofs that concatenate multiple certificates efficiently.
25+
26+
![4 - Integrity](/static/docs/guides/integrity/4-integrity.png)

‎docs/guides/products/integrity/concepts/record-entity.mdx‎

Lines changed: 63 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,63 @@
1+
---
2+
title: 'Record entity'
3+
sidebar_position: 3
4+
---
5+
6+
# The Record entity
7+
8+
The principal element of the BLOOCK SDKs is the Record as it's used on most of the functionalities. It's responsible for different interactions such as:
9+
10+
- Encapsulate your data
11+
- Hashing
12+
- Add [digital signatures](./../../key/overview.mdx#what-digital-signature)
13+
- Add [encryption](./../../key/concepts/operations.mdx#operations)
14+
- Add self-contained metadata
15+
16+
### Record builders
17+
18+
In order to generate a Record, our SDKs provide different builders to do so. Those builders enable to set as input different data types, formats or encodings based on your needs.
19+
20+
#### Available builders
21+
22+
Currently, the following builders are available:
23+
24+
<table>
25+
<thead>
26+
<tr>
27+
<th width="256">Name</th>
28+
<th>Description</th>
29+
</tr>
30+
</thead>
31+
<tbody>
32+
<tr>
33+
<td>fromString</td>
34+
<td>It takes a UTF-8 string as input</td>
35+
</tr>
36+
<tr>
37+
<td>fromBytes</td>
38+
<td>It takes an array of bytes as input</td>
39+
</tr>
40+
<tr>
41+
<td>fromHex</td>
42+
<td>
43+
It takes a hash string (hex encoded 64-chars long string) as input
44+
</td>
45+
</tr>
46+
<tr>
47+
<td>fromJson</td>
48+
<td>It takes a JSON as input</td>
49+
</tr>
50+
<tr>
51+
<td>fromRecord</td>
52+
<td>It takes a record as input</td>
53+
</tr>
54+
<tr>
55+
<td>fromFile</td>
56+
<td>It takes a file (as a byte array) as input</td>
57+
</tr>
58+
<tr>
59+
<td>fromLoader</td>
60+
<td>It takes a Loader as input</td>
61+
</tr>
62+
</tbody>
63+
</table>

‎docs/guides/products/integrity/features/_category_.json‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
{
2-
"position": 4,
2+
"position": 3,
33
"label": "Features",
44
"collapsible": true
55
}

‎docs/guides/products/integrity/features/prepare-data.mdx‎

Lines changed: 1 addition & 66 deletions
Original file line numberDiff line numberDiff line change
@@ -3,77 +3,12 @@ title: 'Prepare data'
33
sidebar_position: 1
44
---
55

6-
# Prepare data
6+
# Prepare data {#prepare-data}
77

88
The first step of the certification process is to prepare the data that you want to certify through BLOOCK.
99

1010
This basically translates to load this data to the SDK, standardize it and compute a hash using the algorithm that BLOOCK uses internally (Keccak256). Luckily, all this process is done by the SDK internally so all you need to do is&#x20;
1111

12-
## The Record entity
13-
14-
The principal element of the BLOOCK SDKs is the Record as it's used on most of the functionalities. It's responsible for different interactions such as:
15-
16-
- Encapsulate your data
17-
- Hashing
18-
- Add [digital signatures](broken-reference)
19-
- Add [encryption](broken-reference)
20-
- Add self-contained metadata
21-
22-
### Record builders
23-
24-
In order to generate a Record, our SDKs provide different builders to do so. Those builders enable to set as input different data types, formats or encodings based on your needs.
25-
26-
#### Available builders
27-
28-
Currently, the following builders are available:
29-
30-
<table>
31-
<thead>
32-
<tr>
33-
<th width="256">Name</th>
34-
<th>Description</th>
35-
</tr>
36-
</thead>
37-
<tbody>
38-
<tr>
39-
<td>fromString</td>
40-
<td>It takes a UTF-8 string as input</td>
41-
</tr>
42-
<tr>
43-
<td>fromBytes</td>
44-
<td>It takes an array of bytes as input</td>
45-
</tr>
46-
<tr>
47-
<td>fromHex</td>
48-
<td>
49-
It takes a hash string (hex encoded 64-chars long string) as input
50-
</td>
51-
</tr>
52-
<tr>
53-
<td>fromJson</td>
54-
<td>It takes a JSON as input</td>
55-
</tr>
56-
<tr>
57-
<td>fromRecord</td>
58-
<td>It takes a record as input</td>
59-
</tr>
60-
<tr>
61-
<td>fromFile</td>
62-
<td>It takes a file (as a byte array) as input</td>
63-
</tr>
64-
<tr>
65-
<td>fromLoader</td>
66-
<td>
67-
It takes a Loader as input (for more information check{' '}
68-
<a data-mention href="broken-reference">
69-
Broken link
70-
</a>
71-
)
72-
</td>
73-
</tr>
74-
</tbody>
75-
</table>
76-
7712
## Examples
7813

7914
import SdkCodeBlock from '/docs/partials/_sdk-code-block.mdx';

‎docs/guides/products/integrity/features/send-data.mdx‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -5,12 +5,12 @@ sidebar_position: 2
55

66
# Send data
77

8-
Once you have your [data prepared](prepare-data.md), you can send it to BLOOCK so it can be certified using our protocol.
8+
Once you have your [data prepared](./prepare-data.mdx#prepare-data), you can send it to BLOOCK so it can be certified using our protocol.
99

1010
When you send a new record to BLOOCK, it's queued internally and assigned to an Anchor. Once this Anchor is processed and transacted into the blockchain, the record gets certified and you will be able to verify it.
1111

1212
:::tip
13-
The certification of a record may take some time to be confirmed. In order to manage this time interval, see [Synchronization](synchronization.mdx).
13+
The certification of a record may take some time to be confirmed. In order to manage this time interval, see [Synchronization](./synchronization.mdx#synchronization).
1414
:::
1515

1616
## Examples

‎docs/guides/products/integrity/features/synchronization.mdx‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,7 @@ title: 'Synchronization'
33
sidebar_position: 3
44
---
55

6-
# Synchronization
6+
# Synchronization {#synchronization}
77

88
Once a data is sent for certification to BLOOCK, there's a time interval until it gets processed and transacted to the different blockchain networks. This time interval can be variable and, in some networks, pretty long,
99

@@ -43,7 +43,7 @@ Once a webhook is configured and a new anchor is processed for one of the select
4343
## Synchronous
4444

4545
:::tip
46-
`It's recommended to only use this method for networks with low internal times (<3 minutes)`
46+
It's recommended to only use this method for networks with low internal times (<3 minutes)
4747
:::
4848

4949
It's also possible to wait for the interval in a synchronous manner by using our SDKs directly. This allows to keep a single code snippet that handles all the certification flow.&#x20;

0 commit comments

Comments
 (0)