FACTOM – FCT – To Understand The Protocol
Hi fellow chaps,
So far we've been discussing general statements about Factom. Some of you might want to know what is the architecture of the protocol and how it works, but don't have the time to do a proper research about it.
Once again, before we stretch our neurons, let's make the difference Factom Foundation (Factom, for future use), who develops the protocol, and Factom Inc (Factom Inc, for future use), who develops apps on top of the protocol. Also, I will describe the protocol as it will be in its final form.
The Factom protocol allows people to post data in the Factom block chain, be they clear data or simply a hash of them (a hash of a document being like a fingerprint of it). Every ten minutes, the Factom protocol takes a hash of the whole Factom block chain and post it in different highly secured block chains (Bitcoin, Ehereum, etc). Thanks to this, at any given time, one is able to say whether a data which was factomized was altered or not. In short, you can verify at anytime the authenticity of a document. In our digital society, the data authenticity market is very important. I'll use the verb to factomize to describe the act of putting data into the Factom block chain through the Factom protocol.
In its final form, the Factom protocol will be made of 64 independent servers. From the 64 servers, 32 will be the so-called Federated Servers, which process the operations of the protocol. The 32 remaining servers are the Audit Servers. They are instant back up for the protocol in case of one or several defective Federated Servers. You kind of have the miners and the watchers, the latter readily available to back up any tired/ill miners.
The picture of the miner is not a trivial thing. There is no miner as we understand it in a traditional crypto way, mining through their GPU/CPU. It was designed this way because the goal of Factom is not merely to factomize documents from a dozen of companies. It is to become a global and world wide used protocol to secure any data. The consequence of that being that the Factom block chain might ends up pretty big, requiring special and dedicated data centers.
The way to chose the Federated and Audit Servers is yet to be determined.
The Factom block chain is made to be business-friendly and thus is able to handle multiple levels of sub-chains. It allows a high degree of organisation, but also of data management. As a company you easily have access to all the data you stored on the Factom block chain, and you can pick the sub-chain you need.
Here is an example already present in the Factom block chain and that we can access through the Factom Explorer:
Here are two sub-chains, Monero and Mastercoin's, of the main Poloniex on. Having this system done, Poloniex can easily compute, verify/prove authenticity of the data it provides through its API, for instance: the prices being stored in the Factom block chain, they are now immutable. You understand it perfectly fits any hierarchical organisation of any company/entity/project/etc.
The Factom protocol and its chain/sub-chains organisation if fairly easy to grasp. Where people are lost is when the duo Factoids (FCT, for future use) and Entry Credits (EC, for future use) is explained. There is already an article (Entry Credit and Factoid’s Source of Value) explaining the necessity of this duo, and why it is brilliant. The ratio EC/FCT is also explained there.
To sum up the previous article, the Federated and Audit Servers will be paid in FCT, to cover the cost of running a dedicated data center by selling them - this creates the supply side of FCT. To factomize a document, you need EC. With one EC, you can store up to 1kb of factomized data. To get EC, you need to burn FCT that were bought beforehand - this creates the demand side of FCT. If the data you want to store weights 10kb, you'll need to burn enough FCT to get 10 EC. Once these 10 EC are provided to the protocol, an Entry is created with your data.
10 EC = up to 10kb of data = a given amount of FCT burned = 1 Entry
The relation between the number of EC you get per amount of FCT burned is:
The consensus price per EC is currently set at 0.001 USD per EC. It will be subject to modification through a consensus among the Federated and Audit Servers.
As you probably understand, on one side the protocol automatically issues a given amount of FCT every specific unit of time. It is done independently of every counter parties of the protocol. And on the other side, FCT are essential to use the protocol. As there are both a limited supply and a demand for them given their utility, Factoids DO have an intrinsic value, that will be determined by the market.
The Factom block chain has already SegWit, on steroids, to paraphrase Paul Snow, chief architect of the Factom protocol. A quote from Factom's father remaining the best:
This point was looked into multiple times already, but have a quick overview of it one more time. The Federated and Audit Servers got automatically paid in FCT by the protocol, creating the supply side of FCT. If you want to store data into the Factom block chain, you need EC. To get EC, you need to burn FCT. Burned FCT are destroyed for good. This action creates the demand side for FCT, this way a market appears where offer and demand will meet, deciding the value of the FCT. I might have repeated this too many times, but it has to be understood as this offer/demand, FCT/EC things are at the core of the protocol.
The Federated and Audit Servers will determine through a consensus the USD price of one EC.
This complete segregation means that an FCT, EC and Entry are not tied. When you burn FCT, you can select the EC address that will receive the new EC. And when you spend your EC, you can choose what data to put in what chain/sub-chain.
You can easily create an ecosystem around the protocol with this architecture. Everybody is currently focused on the success of Factom Inc, but we all have to understand that everybody can build an application on top of the protocol, and market it to potential clients. You can have providers of FCT, providers of EC, and providers of applications, and the union of any assortment of the three. You can become a competitor to Factom Inc.
A company can be specialized in trading FCT, and occasionally burn some to sell their new EC to an EC provider who doesn't want to hold FCT, for operational or regulatory reasons. And an application providers can punctually buy EC to an EC provider to store their clients's data on the Factom block chain. Also, you can provide the full supply chain from buying FCT from the market to storing data on the block chain with the EC gotten from your burned FCT. It is up to you.
The ecosystem around the Factom protocol can be seen as such:
BaaS companies being Block chain as a Service companies.
The more I read about the protocol, the more I realize how brilliant it is. In the near future, when M3 is finalized - M3, i.e. milestone 3, being the final state of the project - the whole protocol will be decentralized and self governed. The Factom protocol is self sufficient, provides the supply it needs to be used, and the current need for a solution to secure data will provide the demand.
So far we've been discussing general statements about Factom. Some of you might want to know what is the architecture of the protocol and how it works, but don't have the time to do a proper research about it.
Once again, before we stretch our neurons, let's make the difference Factom Foundation (Factom, for future use), who develops the protocol, and Factom Inc (Factom Inc, for future use), who develops apps on top of the protocol. Also, I will describe the protocol as it will be in its final form.
The Protocol
Factom Protocol
The Factom protocol allows people to post data in the Factom block chain, be they clear data or simply a hash of them (a hash of a document being like a fingerprint of it). Every ten minutes, the Factom protocol takes a hash of the whole Factom block chain and post it in different highly secured block chains (Bitcoin, Ehereum, etc). Thanks to this, at any given time, one is able to say whether a data which was factomized was altered or not. In short, you can verify at anytime the authenticity of a document. In our digital society, the data authenticity market is very important. I'll use the verb to factomize to describe the act of putting data into the Factom block chain through the Factom protocol.
Federated Servers & Audit Servers
In its final form, the Factom protocol will be made of 64 independent servers. From the 64 servers, 32 will be the so-called Federated Servers, which process the operations of the protocol. The 32 remaining servers are the Audit Servers. They are instant back up for the protocol in case of one or several defective Federated Servers. You kind of have the miners and the watchers, the latter readily available to back up any tired/ill miners.
The picture of the miner is not a trivial thing. There is no miner as we understand it in a traditional crypto way, mining through their GPU/CPU. It was designed this way because the goal of Factom is not merely to factomize documents from a dozen of companies. It is to become a global and world wide used protocol to secure any data. The consequence of that being that the Factom block chain might ends up pretty big, requiring special and dedicated data centers.
The way to chose the Federated and Audit Servers is yet to be determined.
Chains & Subchains
The Factom block chain is made to be business-friendly and thus is able to handle multiple levels of sub-chains. It allows a high degree of organisation, but also of data management. As a company you easily have access to all the data you stored on the Factom block chain, and you can pick the sub-chain you need.
Here is an example already present in the Factom block chain and that we can access through the Factom Explorer:
 |
 |
Entry, Factoids & Entry Credit
The Factom protocol and its chain/sub-chains organisation if fairly easy to grasp. Where people are lost is when the duo Factoids (FCT, for future use) and Entry Credits (EC, for future use) is explained. There is already an article (Entry Credit and Factoid’s Source of Value) explaining the necessity of this duo, and why it is brilliant. The ratio EC/FCT is also explained there.
To sum up the previous article, the Federated and Audit Servers will be paid in FCT, to cover the cost of running a dedicated data center by selling them - this creates the supply side of FCT. To factomize a document, you need EC. With one EC, you can store up to 1kb of factomized data. To get EC, you need to burn FCT that were bought beforehand - this creates the demand side of FCT. If the data you want to store weights 10kb, you'll need to burn enough FCT to get 10 EC. Once these 10 EC are provided to the protocol, an Entry is created with your data.
The relation between the number of EC you get per amount of FCT burned is:
The consensus price per EC is currently set at 0.001 USD per EC. It will be subject to modification through a consensus among the Federated and Audit Servers.
As you probably understand, on one side the protocol automatically issues a given amount of FCT every specific unit of time. It is done independently of every counter parties of the protocol. And on the other side, FCT are essential to use the protocol. As there are both a limited supply and a demand for them given their utility, Factoids DO have an intrinsic value, that will be determined by the market.
SegWit on Steroids
The Factom block chain has already SegWit, on steroids, to paraphrase Paul Snow, chief architect of the Factom protocol. A quote from Factom's father remaining the best:
"Factom is SegWit on steroids.
The fct transactions are tracked and accounted for separately from Entry Credit balances. Entry Credit balances pay for data >that is placed into factom. Think of them as prepaid fees. And Entry Credit balances are tracked separately from the data.
Finally, the data is organized such that users place information important to them into particular chains that they define. >Those chains can be managed and proven separately from all the other data.
Segregation means that users only need to look at small segments of data. And ultimately this means that not all nodes in the >system have to track all the data.
So in the end, factom is distributed data. While most blockchains are distributed computation. The latter is quite a bit more >expensive than the former.
Paul Snow - Architect of the Factom Protocol
Again, Factom thinks big and foresee a broad use of its protocol. Plus, this statement can easily be verified through the explorer. Let's take this block, #99633. We have:
Overview of FCT/EC relation
This point was looked into multiple times already, but have a quick overview of it one more time. The Federated and Audit Servers got automatically paid in FCT by the protocol, creating the supply side of FCT. If you want to store data into the Factom block chain, you need EC. To get EC, you need to burn FCT. Burned FCT are destroyed for good. This action creates the demand side for FCT, this way a market appears where offer and demand will meet, deciding the value of the FCT. I might have repeated this too many times, but it has to be understood as this offer/demand, FCT/EC things are at the core of the protocol.
The Federated and Audit Servers will determine through a consensus the USD price of one EC.
Creation of an ecosystem
This complete segregation means that an FCT, EC and Entry are not tied. When you burn FCT, you can select the EC address that will receive the new EC. And when you spend your EC, you can choose what data to put in what chain/sub-chain.
You can easily create an ecosystem around the protocol with this architecture. Everybody is currently focused on the success of Factom Inc, but we all have to understand that everybody can build an application on top of the protocol, and market it to potential clients. You can have providers of FCT, providers of EC, and providers of applications, and the union of any assortment of the three. You can become a competitor to Factom Inc.
A company can be specialized in trading FCT, and occasionally burn some to sell their new EC to an EC provider who doesn't want to hold FCT, for operational or regulatory reasons. And an application providers can punctually buy EC to an EC provider to store their clients's data on the Factom block chain. Also, you can provide the full supply chain from buying FCT from the market to storing data on the block chain with the EC gotten from your burned FCT. It is up to you.
Simplified view of the Factom ecosystem
The ecosystem around the Factom protocol can be seen as such:
BaaS companies being Block chain as a Service companies.
Conclusion
The more I read about the protocol, the more I realize how brilliant it is. In the near future, when M3 is finalized - M3, i.e. milestone 3, being the final state of the project - the whole protocol will be decentralized and self governed. The Factom protocol is self sufficient, provides the supply it needs to be used, and the current need for a solution to secure data will provide the demand.
It is a brilliant protocol and cool idea.
However, I don't like the price at the moment. At current price levels 1.2 billion entry credits need to be spent to reach an equilibrium with FCT creation. This is several thousand times higher than the current usage.
I also am negative on Factom Inc. making their own profits. So we have to rely on the corporation to maintain a good relationship with the current token.
Then a technical point I don't understand (so not holding it against my valuation): Why do you need the federated servers? After you hash your document, don't you have all the evidence you need that the document existed at some point in time? You can upload the hash anywhere, right?
Hi mate,
For the price, agreed. But don't neglect the speculative part. Most tokens have crazy valuation with current no usecase. Factom is in production already.
The federated servers are here to process the blocks and keep the hash in the Factom Blockchain. They decided to have a limited number of dedicated servers for the simple reason that if Factom is successful, the average joe won't have the material to hold that much data. "After you hash your document..." After you hashed your document, you still need a decentralized system to hold your hash. To make it short, the federated servers both process the blocks and hold the data in a decentralized ledger.
Haven't looked much into Factom myself, definitely a contender. Thank you for putting this together!
Don't hesitate to read my previous articles to have a complete overview ;)
https://cryptozod.wordpress.com/