Progressive Data Management

These endpoints represent the core of the functionalities of the IdA Nodes. Writing, but above all reading the information written on the blockchain represent the two key features of the development of any dApp.

We remember that the writing of arbitrary data is allowed thanks to the OP_RETURN, which allows to insert 80 bytes of data on any transaction. It is important to understand that the outputs marked with OP_RETURN are non-expendable transactions, in fact the sole fees of 0.001 LYRA are charged for each transaction, ie for every 80 bytes.

If the data size to be written exceeds 80 bytes, IdaNode (and Scrypta Core) divides the data into 74-byte pieces and uses the first 3 bytes and the last 3 bytes to create a link between sequential data. In particular the first 3 bytes are linked to the previous transaction and the last 3 to the next one. In this way, IdA Nodes are able to reconstruct written information on multiple transactions.

This system is a solution that allows you to bypass the limits imposed by the blockchain. Increasing the size of OP_RETURN from 80 bytes to a higher size would result in the risk of spam in the network, so it was decided to keep it as originally established. Written on multiple transactions.

Operations

The possible operations through Progressive Data Management are of three types:

  1. Writing: for writing operations are meant all those transactions with OP_RETURN to and from the same address, this means that each address of the blockchain can write information about itself. This means that an address can expressly write information whose ownership can be demonstrated without any doubt.

  2. Update: the update operations require the writing of sequential data always referring to the same UUID. This does not mean that the information can be altered, but rather - by convention - that the most up-to-date information is returned. It is always possible to retrieve the history of updates by passing the parameter history = true when reading, as we will see below.

  3. Invalidation: invalidation operations are necessary to communicate to the Ida Node that a given data should not be shown during the reading phase. As already specified, this invalidation (which consists in updating the data with metadata "END") does not actually delete the data that can always be retrieved during reading by passing the history = true parameter.

According to our protocol, a typical structured data is the following:

{
"_id":"5da9dd2724d7e32a34b32660",
"address":"Lf2GteRJavZKWvVGryFuhkio5jdi1G6LeN",
"uuid":"ddececf4.6265.4542.97c5.cabb6e320111",
"collection":"",
"refID":"",
"protocol":"",
"data":"Hello world.","block":55650,
"blockhash":"0219d55c6ef7c33e73eab0116faee40a92541ee931ad07cabd97b5ee5c0278d8",
"time":1548755949
}

As we have seen in the Scrypta Core documentation, we have several filters:

  • collection: defines a collection.

  • refID: defines a single reference identifier.

  • protocol: defines a protocol, usually interpreted by the dApp.

  • uuid: unique identifier assigned during writing. This uuid is essential for update and invalidation operations as it must be passed to endpoints.

Another type of filter is the send, which however is not considered in the same way as the write / update / invalidation operations by the IdaNode. By sending operations we mean the single transaction with OP_RETURN from an address to another address. This is limited to a maximum of 80 bytes and the content is not formatted according to the above standard. As we can see in the example below, a UUID is not assigned and the elements for Collection, RefID, Protocol cannot be filtered. Clearly, however, there is a sender field that defines who sent the data. This type of data is useful in the development of dApps that provide for the exchange of information between two or more addresses as shown in our voting platform's Proof of Concept.

{
"_id":"5da9e65324d7e32a34b76931",
"txid":"b1a457c270d1ecfa49bfa7b390756213a3746c15c7e21249a9010e3fbaadf7ba",
"block":118432,
"address":"LauYFGNdYfWfKeEpZzkXvxu7wt4r9YeUkf",
"sender":"6JYZgQqSytCwyAFBUYPKFQAccvb6SzjeW8",
"data":"poll://VOTE:1"
}

[POST] /write

Scrive le informazioni all’interno della blockchain. Quando invocata attraverso l’IdaNode è necessario inviare anche la chiave privata dell’indirizzo che sta scrivendo le informazioni.

It is clear that the security measures must be taken with the necessary caution, we need the private keys to be guaranteed safe. It is clear that the security measures must be taken with the necessary caution so that the private keys remain effectively secure. We advise against exposing the IdANode on the Internet without the installation of SSL certificates.

Here is the list of parameters:

  • dapp_address [mandatory]: the address that is writing the information.

  • date [mandatory]: the information you want to write in the blockchain.

  • private_key [mandatory]: the private key of the address that is writing the information.

  • file: a file that can be written to IPFS at the same time.

  • protocol: the protocol you want to use to classify information.

  • collection: the collection you want to use to classify information.

  • refID: the reference ID you want to use to classify information.

  • uuid: the unique identifier assigned by the IdA Node to update a given data.

The answer will be very similar to writing through Scrypta Core:

{
"uuid": "c95a77da.9683.499a.aeb5.8d47c202d126",
"address": "LdRQokR1i3XDtj1V3jnCRqMPrVc7sYkeE2",
"fees": 0.002,
"collection": "",
"refID": "",
"protocol": "dapp://",
"dimension": 107,
"chunks": 2,
"stored": "*!*c95a77da.9683.499a.aeb5.8d47c202d126!*!!*!!*!dapp://*=>Qmb8PCFSp9uSUJr3eLafiTyAqcHaq2TBk4kj4wAEDG2zQo*!*",
"txs": [
"1cc6ce97780634cd0a181aea539a09694592beca1cb0406d0b85a7268872ed5f",
"33d682f861665928a634a10d4e75f7c99038d4b7536498c9d17598d8552ac007"
]
}

[POST] /invalidate

It is used to invalidate a data, the parameters necessary for the operation are:

  • uuid [mandatory]: the unique identifier returned by the Ida Node in the initial writing phase.

  • private_key [mandatory]: private key of the address that wrote the information.

  • dapp_address [mandatory]: the address that wrote the information.

The answer will be similar to this:

{
"uuid": "07ec884b.3575.4d94.a65f.5afdd5c7bd46",
"address": {},
"fees": 0.001,
"success": true,
"txs": [
"648ceeb581b7b26897e211ff652c5adaaa878fe16a5454156d058099a7bc87e5"
]
}

[POST] /read

The information is read only by this call. It is possible to filter and limit the results, as well as read all the information written on the blockchain in a sort of feed, just like in our service: https://proof.scryptachain.org.

The parameters that can be sent are the following:

  • history: allows you to set the return of updated or invalidated data, by default it isfalse.

  • address: filters the data written by a specific address.

  • uuid: filters the data by choosing a specific uuid, if used in combination with the history field it is possible to view the history of a given data.

  • collection: filters the data for a given collection.

  • refID: filters the data by choosing a specific refID. It is possible to use it as an alternative to the uuid, but using its own type of identifier (numeric, alphanumeric, etc).

  • protocol: filters the data for a given protocol.

The answer of the property data will be an array of objects containing what is required. This call, for example, was obtained by simply passing limit = 2 and history = false.

{
"data": [
{
"_id": "5dad7b8d2d710a290dff6c68",
"address": "LdRQokR1i3XDtj1V3jnCRqMPrVc7sYkeE2",
"uuid": "a77da.9683.499a.aeb5.8d47c202d126",
"collection": "",
"refID": "",
"protocol": "dapp://",
"data": "Qmb8PCFSp9uSUJr3eLafiTyAqcHaq2TBk4kj4wAEDG2zQo",
"block": 432255,
"blockhash": "1b0da19047e3016bc31d20fc95e66e5bd16140810d6f957c11ffd88ff487ecd0",
"time": 1571650471,
"is_file": false
},
{
"_id": "5da6e5ad05e0ac4fb02ecd08",
"address": "LLLjx7yV4nhUzSapBAHogb5BdgUR6VCB3o",
"uuid": "2b33e.a4e8.401e.b32b.a2b75b012554",
"collection": "",
"refID": "",
"protocol": "",
"data": "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis quis risus auctor, eleifend neque sit amet, ultricies nulla. Suspendisse condimentum nisi ut nunc mattis, vel congue velit congue. Aliquam sit amet pharetra tellus. Etiam tellus lacus, pretium vel commodo a, tempor nec ante. Aenean turpis nisi, pulvinar eget vehicula at, dapibus at dui. Cras vitae dictum massa. Sed in orci lorem. Nullam ut mattis lacus. Mauris ut mattis tellus. Donec et posuere lorem, id elementum ligula. Aliquam eu mollis neque, eget venenatis erat. Aenean vestibulum nunc diam, et luctus massa porttitor ac. Morbi tempor eleifend bibendum. Curabitur sed diam leo.",
"block": 425161,
"blockhash": "2fba2b7988f70b035b2563444057b98ac6fc2fac4d1643e454f1f466a6d046d5",
"time": 1571218881,
"is_file": false
}
],
"status": 200
}

[POST] /received

It allows you to read all the information received from a specific address. The only parameter that can be sent is address and the answer obtained is similar to that of the endpoint / read. Here an example:

{
"data": [
{
"_id": "5d921a86543b974a0ef91567",
"txid": "0d2ad08aa7fbd2eb2a2a237b7a7082b69c8e77c038fd5aeb422a0ccadd760e30",
"block": 267699,
"address": "LKXyszE4EQGRZZKuua5qdyu7PuGuowQHX4",
"sender": "LY6BHLvjNbHCQxnpGgt6BvXhXjfX6Nk1X2",
"data": "hola!",
"is_file": false
}
],
"status": 200
}