Jan 27, 2018

[2] Blockchains

I've noticed that there is a common misconception that blockchain and bitcoin are the same thing. The reason for this might be that bitcoin was the first to implement blockchain as a core component to serve as the public ledger for all its transactions. But what is a blockchain and why does bitcoin use one?

As the name implies, a blockchain is a chain of blocks. The blocks store encrypted information about transactions and also information about themselves and where they come from. Each individual blockchain stores different kinds of information, but they all have a hash and the hash of the previous block. The chain part is given by the fact that each block contains information about the previous block, thus creating a chain. Originally this was conceptualized in 1991, and it was meant to avoid backdating or tempering documents. The security of each blockchain is dependent on the ways different properties are implemented. This include the hashing function, the proof-of-work and the distributed network.

The blockchain is a distributed ledger open to anyone and managed by a peer-to-peer network.When a new block is created, it is sent to all the members of the network. Then each member verifies the block and adds it to the chain. All the nodes in the network create consensus. If a block has been tampered, it will be rejected by the nodes and not added to the chain.

Each block is identified by what is called the hash. A hash is a unique identifier generated by a hashing function. Any change in the block would result in a change of the hash. This is because one of the properties of a hashing function is that a particular output will result from a particular input, and only from that particular one, so if you change any part of the input this will modify the output. Another important property is that the function is non-invertible.

The proof-of-work will require some processing time from the service requester. This time can vary, in the case of bitcoin is 10 minutes but in other cryptocurrencies times go usually from 10 to 14 seconds. This process makes tampering older blocks very complex, as it would be needed to recalculate the proof-of-work for all the blocks that follow the tampered one.

More info:
How does a blockchain work
Understand the blockchain in two minutes
Blockchain in 5 levels of difficulty

Jan 13, 2018

[1] RESTful web services

REST stands for REpresentational State Transfer, and in one sentence I would say that REST is an architectural style. So it is not a thing, we can't point at it, what we can do is check if a particular system follows RESTful rules and principles.

REST was defined first in Roy Fielding's doctoral dissertation and it "(...)has been used to guide the design and development of the architecture for the modern Web"(1). It is resource based, which means in REST we talk about things or resources that we identify through the URI (Uniform Resource Identifier). Resources have representations, but they are not the same, the representation is not the resource itself. The representation is how the resource gets manipulated, and consists of data and metadata which is in the form of name-value pairs. Those representations are transferred between client and server usually in JSON or XML.

To have a RESTful system it has to follow a set of six constraints. Those constraints are applied to the architecture in order to  allow scalability, simplicity, modifiability, visibility, portability, reliability and maintainability.

The first constraint is Uniform Interface, which defines the interface between client and server. This is central to REST architectural style and helps improve the visibility of the interactions. Another advantage is that it decouples and simplifies the architecture. There is one trade-off, and that is that uniform interface degrades efficiency. This happens because the information is transferred in a standardised form, rather than a specific one. "The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimising for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction"(2). The four guiding principles to have a uniform interface are that it is resource-based, resources are manipulated through representations, messages are self-descriptive and Hypermedia As The Engine Of Application State (HATEOAS).

The second constraint is Statelessness, this means that the server contains no client state. This is because each request is self-descriptive, so it contains enough context to process the message. Any session state is held on the client. This constraint helps us achieve visibility, reliability and scalability but it also comes with the trade-off that it may decrease network performance. This is due to the fact that repetitive data is increased.

Client-server is the third constraint. A disconnected system with separation of concerns has to be assumed. Separating the user interface and data storage concerns allows for easier portability across platforms and scalability. Also the components can evolve independently.

Another constraint in RESTful architectures is that they must be Cacheable. This is in order to improve network efficiency. Server responses (or representations) must be explicitly or implicitly labeled as either cacheable or non-cacheable. Cacheable data allows the client to reuse the information in a particular response, and this eliminates some future interactions and improves efficiency.

The Layered System constraint "(...)allows an architecture to be composed of hierarchical layers by constraining component behaviour such that each component cannot "see" beyond the immediate layer with which they are interacting"(3). Clients can't assume direct connection to the server, the information being retrieved can be cached. This improves scalability.

The sixth constraint is the only optional one. Optional constraint seem to be two contradictory words but, "An optional constraint allows us to design an architecture that supports the desired behaviour in the general case, but with the understanding that it may be disabled within some contexts"(4). The Code on demand constraint means that the server can temporarily extend a client by transferring logic to the client as a representation. This allows the client to execute this logic.

Violating any of this constraints means that the service is not strictly RESTful.

To read more: 

First things first

Before I write anything I just want to say. Assume that anything that is written here might not be 100% accurate. My goal with this is to learn, and to do so I try to write short articles about what I learn. This means I am not a professional of anything discussed here and I might have understood it wrong. Comments will be welcome to point it out if you feel it is necessary, and corrections will be placed if I feel it is necessary. So that, take everything here with a grain of salt.