Comentarios Sobre Hyperledger (HLFV1)

y ALASTRIA:
1. General requirements
1.1. Based on OpenSource of wide acceptance in the
market
To minimize as much as possible any dependencies on any specific vendor. In particular:

1. Alastria will not develop its own blockchain, but will use a widely used one.
2. Alastria will not incorporate any proprietary components or force to the members
to use any proprietary component.
3. The software used by Alastria should be built by an OpenSource community as
wide and as diverse as possible. [[LO cumple HLFv1]]

1.2. The ecosystem of users of the software should be

as wide as possible
To minimize the risks of using software will will stop being developed in the future. It
also makes sure that the innovation rate is high and is also evolving rapidly. In particular:

1. Ecosystem of developers using the software as wide as possible

2. Ecosystem of applications using the software as wide as possible
3. Ecosystem of knowledge about the software as wide as possible

[[Los 3 los cumple HLFv1]]

1.2. Alastria should be based on general-purpose and

multi-industry platforms
Alastria has to support all the different use cases that can appear in a multi-industry
blockchain country network, so Alastria will avoid any software which is specific to one
industry or is too specialised. That means that there may be some very specialized use
cases that are not supported by Alastria, at least at the beginning. The challenge here is
to be able to interoperate between different blockchain networks. One possibility being
actively investigated is the ability to run in parallel two (or more) blockchain networks
with different technology, to be able to support a wider spectrum of use cases.

[[HLFv1 incluye varios elemntos de interoperabilidad entre cadenas usando el

concepto de que un mismo peer puede estar conectado a varias cadenas, o canales,
es decir incluyendo uno o mas ledgers, asi mismo puede intercambiar eventos off-
chain que se codifican dentro del Smart contract (chaincode) ]]

1.3. Alastria will allow and facilitate regulatory

compliance by the members, in particular:
(In Spanish because we are currently focusing on the specific problems of Spanish
regulation).

1. Reglamento General de Protección de Datos (RGPD)

2. Ley de Servicio de Sociedad de la Información y Comercio Electrónico (LSSI)
3. Reglamento de prevención del blanqueo de capitales y de la financiación del
terrorismo
4. Normas y recomendaciones del Consejo Nacional de Ciberseguridad
5. Others

[[HLFv1 tiene un fuerte mecanismo de permisionado, encritado y verificación de

firma digital que cumle con las regulaciones citadas]]

2. Technical requirements
2.1. Privacy
2.1.1. Privacy of Transactional Activity
The members participating in private contracts or transactions should have total privacy
of their activity with respect to the other members of Alastria. That is, a member should
not be able to see the private activity of any other member if it does not participate
itself in that activity. This point does not refer just to data visibility, but also to the actual
transactional activity.

2.1.2. Privacy of Data

2.1.2.1. No PII data (Personally identifiable information) should be stored in the

Blockchain

Alastria can not enforce this just with technical means, so this is more a
recommendation to the members. In general, all sensitive data should be stored off-
chain, and Alastria will not implement anything that forces sensitive information to be
stored in the blockchain.

[[ HLFv1 no escribe ninguna PII en la cadena de bloques]]

2.1.2.2. Reference architecture for data storage

Alastria should not force the members to store their data in any specific storage system.
Each member should be able to decide which storage system they want to use for each
specific type of data items they handle. However, Alastria will provide an architecture
and reference implementation that can facilitate to the members and efficient,
interoperable and secure storage system.

 Some data could be stored in mobile devices owned by the user.

 Some data could be stored in systems like Constellation from Quorum.
 Some data could be stored in distributed storage systems without access control,
like IPFS.
 Some data could be stored in non-distributed storage systems with access
control, like WebDAV.
 Some data could be stored in the current systems that act like custodians (eg.
banking data, health, ect).

[[ HLFv1 puede exporter off chain datos a cualqueira de los almacenamientos

comentados en este punto usando eventos o las queries de CouchDB]]
2.2. Fault Tolerance

2.2.1. Byzantine Fault Tolerance

The system should tolerate attacks from a given number (limited) of nodes and
participants behaving maliciously in a deliberate manner.

[[ HLFv1 incluye PBFT]]

2.2.2. Modular mechanism to upgrade consensus algorithms

Consensus algorithms are evolving very fast. The system should allow to incorporate
easily new algorithms, if they are considered adequate for the needs of Alastria.

[[LO cumple HLFv1]]

2.3. Performance

1. Throughput around 1.000 tx/s [[ HLFv1 ha sido testeado con 10000 t/s]]
2. Without performance degradation due to transaction overload. [[LO cumple
HLFv1]]
3. Computational load required for validation of blocks should be independent from
time or size of the blockchain. [[LO cumple HLFv1]]
4. Time required for data access from blockchain should be constant. ". HLFv1
puede tunearse para dejar consratnet el tiempo de acceso a datos
5. Should support "pruning" of the blockchain, to facilitate "light clients". HLFv1
permite el prunnig o checkpointing …vease: http://hyperledger-
fabric.readthedocs.io/en/release/arch-deep-dive.html#post-v1-validated-ledger-
and-peerledger-checkpointing-pruning

2.4. Settlement Finality

1. Transaction finality should be deterministic and considered final in one block. ".
HLFv1 esta diseñado para ser determinista (finality)
2.5. Without embedded cryptocurrencies
In order to achieve zero or very low and predictable transaction costs (non-zero
transaction costs could be required for anti-spam and network-protection mechanisms).

". HLFv1 no tiene una criptocuurrency embebida

2.6. Anti-spam

1. Anti-spam mechanism to protect the network from nodes and participants that
generate excessive load. ".
2. Mechanism to stop immediately entities which initiate transactions above a
certain level

". HLFv1 en ambos casos puede detectarse en el proceso de endorsement, y asi

mismo puede incluirse en el codigo de chaincode un codigo de autolimitación del
tiempo de ejecución

2.7. Permissioning

1. Permissioning of individual nodes and of participant addresses

2. Whitelist and blacklist of nodes and participant addresses

". HLFv1 dispone de un potente sistema de permisionado en base a eCerts x509

con CRLs gestionados por un conjunto de nodos de memberships que usan nodos
que actúan de CA/RA

2.8. Maximise decentralisation

The objective of Alastria is to be as much as possible a public network, in contrast to a
private consortium. When adopting any decision, the option chosen should be the one
which maximises decentralisation, assuming that the rest of requirements are achieved.

". HLFv1 esta formados por nodos peer, ordering (consenso) y membership (+CA)
absolutamente descentralizados.

2.9. Inter-node connectivity

 1. Minimise the need for direct point-to-point connectivity between participant
nodes.
2. Minimise the need for direct point-to-point connectivity between participant
nodes in private transactions and contracts.

". HLFv1 se ha diseñado para hacer mínimo el número de interacciones

punto a punto entre nodos participantes. Para ello, el proceso de
endorsement (validación) se raliza utilizando el minimo numero prible de
peers. Los protocolos de HLFv1 tratan de evitar interacciones redundantes
tanto en en el proceso de membership, como el endorsement como el
ordering

2.10. Synchronisation and Disaster Recovery

1. Mechanism for fast synchronisation of the blockchain for nodes which connect
for the first time, both for the public and the private parts.

". HLFv1 solo maneja <<private parts>> . Los nodos (u organizaciones) que se
conectan por primera vez pueden utilizar una tool específica (llamada
configtxlator) para acelerar la configuracion y sincronización.

2. Mechanism that allows starting a new node from the backup of another node, till
a given block.

Backup/restore en ledgers/nodes de HLFV1:

Ledger backup
It is not required to backup the ledger data of a peer. This is because, even in the worst case of
catastrophic failure of a peer (e.g, a disk failure) , the peer can be brought up with no ledger at
all. The peer can then re-join the desired channels and as a result, the peer will automatically
create a ledger for each of the channels and eventually will receive the blocks via regular block
transfer mechanism from other peers in the channel.
Still, some organizations may want to be more self-reliant and hence may want to take backup of
their ledger data so as to be able to recover from catastrophic failures and resume from thereon.
In addition, ledger data backups may help to expedite the addition of a new peer in the channel
which can be achieved by backing up the ledger data from one peer and starting the new peer
with the backed up ledger data.
In order to back up the ledger data of a peer, perform the following steps.
1. Stop the peer
2. Backup the folder `<peer.fileSystemPath>`/ledgersData.
`<peer.fileSystemPath>` refers to the value of the property specified in the configurations
(core.yaml) - default value of this property is `/var/hyperledger/production`
In the step 2 above, some of the sub-folders under `<peer.fileSystemPath>`/ledgersData can be
skipped while backing up the ledger data.
These sub-folders include `stateLeveldb`, `historyLeveldb`, `chains/index`. Skipping these
folders reduces the storgae demand for the backup however, at the same time, the peer
recovery from the backedup data may take more time. This is cause by the fact that the
information in these folders (i.e., the state db, history db, and indexes on blocks) is re-
constructed when the peer starts.
In order to restore the ledger data to a fresh peer, perform the following steps.
1. Copy the backed-up folder at `<peer.fileSystemPath>`/ledgersData
2. Start the peer