|Fred Hampton 0a95ffaacd Update 'README.md'||2 months ago|
|LICENSE||2 months ago|
|README.md||2 months ago|
Following Dr. King's memorial services on May 2, 1968, Coretta Scott King and Ralph Abernathy launched the Freedom Train from Memphis, Tennessee, the first caravan of the Poor People’s Campaign.
Half a century ago, humanity witnessed the assassinations of 2 of its brightest lights – Martin Luther King Jr. and Robert F. Kennedy. The world still grieves for the loss of these two great visionaries, and for their dreams of social justice and equality.
With the introduction of Douglass and the FreedomTrain, humanity moves a step closer to the realization of a world of social justice and equality for all humans.
Freedomtrain is a Blockchain powered economic system that is socially redistributive (not merely correcting inequalities after the fact), and ecologically regenerative (not merely repairing the damage previously done).
FreedomTrain creates an operating system-like architecture that gives developers the ability to create decentralized applications. FreedomTrain provides accounts, authentication, databases, asynchronous communication, and the scheduling of applications across many CPU cores or clusters.
FreedomTrain’s blockchain architecture allows for scaling to millions of transactions per second, eliminates user fees, and allows for quick deployment and maintenance of decentralized applications, in the context of a Beloved Community governance framework.
First Blockchain and Currency Platform aligned with the Beloved Community License and Buddha Economics.
For Blockchain applications to become viable they will need to be capable of handling tens of millions of active daily users. Many application may not work without a critical mass of users . FreedomTrain is a Blockchain platform that can handle millions of users.
To gain widespread adoption the FreedomTrain platform is free to use.
Server hosting and cloud storage are part of FreedomTrainm. This means that application developers can build and deploy applications and web interfaces with hosting, cloud storage, and download bandwidth provided by the system. This opens developers up to bring their ideas into reality free from the demands of securing storage and bandwidth.
As a developer, you have access to usage analytics for storage and bandwidth directly from Freedomtrain and are able to set limits for specific applications to whatever levels you choose.
FreedomTrain based applications have the ability to dynamically enhance their applications with new features. FreedomTrain supports dynamic software and smart contract upgrades. The FreedomTrain Platform dynamically repairs algorithm issues in real time.
The FreedomTrain user experience provides reliable feedback with delays of only a few seconds.
The FreedomTrain Platform provides low latency transactions.
High intensity applications such as crypto exchanges and enterprise supply chain applications need sequential performance to handle high volumes. Therefore, the platform should support fast sequential performance.
FreedomTrain Enables Parallel Performance FreedomTrain gives Large scale applications the ability to divide workloads across multiple CPUs and computers.
FreedomTrains utilizes a BCL aligned Delegated Proof of Stake (DPOS) the only known decentralized consensus algorithm proven capable of meeting the high performance requirements of applications on the blockchain,
With the BCL aligned Delegated Proof of Stake, Block chain produces are individuals or institutions chosen by the community that are aligned with the BCL and the principals of Buddha Economics
FreedomTrain enables blocks to be produced every 0.5 second and only one producer is authorized to produce a block at any given point in time. If the block is not produced at the scheduled time, then the block for that time slot is skipped. When one or more blocks are skipped, there is a 0.5 or more second gap in the blockchain.
FreedomTrain blocks are produced in rounds of 138 (6 blocks each, times 23 producers). At the start of each round 23 unique block producers are chosen by preference of votes cast by token holders. The selected producers are scheduled in an order agreed upon by 15 or more producers.
If a producer misses a block and has not produced any block within the last 24 hours they are removed from consideration until they notify the blockchain of their intention to start producing blocks again. This ensures the network operates smoothly by minimizing the number of blocks missed by not scheduling producers who are proven to be unreliable.
Under normal conditions a DPOS blockchain does not experience any forks because, rather than compete, the block producers cooperate to produce blocks. In the event there is a fork, consensus will automatically switch to the longest chain. This method works because the rate at which blocks are added to a blockchain fork is directly correlated to the percentage of block producers that share the same consensus. In other words, a blockchain fork with more producers on it will grow in length faster than one with fewer producers, because the fork with more producers will experience fewer missed blocks.
No block producer should be producing blocks on two forks at the same time. A block producer caught doing this will likely be voted out. Cryptographic evidence of such double-production may also be used to automatically remove abusers.
Byzantine Fault Tolerance is added to traditional DPOS by allowing all producers to sign all blocks so long as no producer signs two blocks with the same timestamp or the same block height. Once 15 producers have signed a block the block is deemed irreversible. Any byzantine producer would have to generate cryptographic evidence of their treason by signing two blocks with the same timestamp or blockheight. Under this model a irreversible consensus should be reachable within 1 second.
DPOS blockchains have 100% block producer participation. A transaction can be considered confirmed with 99.9% certainty after an average of 0.25 seconds from time of broadcast.
In addition to DPOS, FreedomTrain adds asynchronous Byzantine Fault Tolerance (aBFT) for faster achievement of irreversibility. The aBFT algorithm provides 100% confirmation of irreversibility within 1 second.
FreedomTrain requires every transaction to include part of the hash of a recent block header. This hash serves two purposes:
FreedomTrain permits all accounts to be referenced by a unique human readable name of up to 12 characters in length. The name is chosen by the creator of the account. Account creators must reserve the RAM required to store the new account until the new account stakes tokens to reserve its own RAM.
All accounts can send structured Actions to other accounts and may define scripts to handle Actions when they are received. FreedomTrain gives each account its own private database which can only be accessed by its own action handlers. Action handling scripts can also send Actions to other accounts. The combination of Actions and automated action handlers is how FreedomTrain defines smart contracts.
To support parallel execution, accounts can also define any number of scopes within their database. The block producers will schedule transaction in such a way that there is no conflict over memory access to scopes and therefore they can be executed in parallel.
FreedomTrain provides a declarative permission management system that gives accounts fine grained and high-level control over who can do what and when.
It is critical that authentication and permission management be standardized and separated from the business logic of the application. This enables tools to be developed to manage permissions in a general-purpose manner and also provide significant opportunities for performance optimization.
Every account may be controlled by any weighted combination of other accounts and private keys. This creates a hierarchical authority structure that reflects how permissions are organized in reality and makes multi-user control over accounts possible. Multi-user control greatly reduces the risk of theft due to hacking.
FreedomTrain gives account holders the ability to define what combination of keys and/or accounts can send a particular Action type to another account. It is possible to have one key for a user's social media account and another for access to the FreedomTrain exchange. It is also possible to give other accounts permission to act on behalf of a user's account without assigning them keys.
With FreedomTrain accounts users can define named permission levels each of which can be derived from higher level named permissions. Each named permission level defines an authority; an authority is a threshold multi-signature check consisting of keys and/or named permission levels of other accounts. For example, an account's "Friend" permission level can be set for an Action on the account to be controlled equally by any of the account's friends.
FreedomTrain enables all account to define a mapping between a contract/action or contract of any other account and their own Named Permission Level. It is possible for an account holder to map the account holder's social media application to the account holder's "Friend" permission group. With this mapping, any friend could post as the account holder on the account holder's social media. Even though they would post as the account holder, they would still use their own keys to sign the Action. This means it is always possible to identify which friends used the account and in what way.
When delivering an Action of type "Action", from @alice to @bob the FreedomTrain will first check to see if @alice has defined a permission mapping for @bob.groupa.subgroup.Action. If nothing is found then a mapping for @bob.groupa.subgroup then @bob.groupa, and lastly @bob will be checked. If no further match is found, then the assumed mapping will be to the named permission group @alice.active.
Once a mapping is identified then signing authority is validated using the threshold multi-signature process and the authority associated with the named permission. If that fails, then it traverses up to the parent permission and ultimately to the owner permission, @alice.owner.
FreedomTrain allows all accounts to have an "owner" group which can do everything, and an "active" group which can do everything except change the owner group. All other permission groups are derived from "active".
The permission evaluation process is "read-only" and changes to permissions made by transactions do not take effect until the end of a block. This means that all keys and permission evaluation for all transactions can be executed in parallel. Furthermore, this means that a rapid validation of permission is possible without starting costly application logic that would have to be rolled back. This also means that transaction permissions can be evaluated as pending transactions are received and do not need to be re-evaluated as they are applied.
Permission verification represents a significant percentage of the computation required to validate transactions. Making this a read-only and trivially parallelizable process enables a dramatic increase in performance.
When replaying the blockchain to regenerate the deterministic state from the log of Actions there is no need to evaluate the permissions again. The fact that a transaction is included in a known good block is sufficient to skip this step. This dramatically reduces the computational load associated with replaying an ever growing blockchain.
FreedomTrain gives application developers the ability to indicate that certain Actions must wait a minimum period of time after being included in a block before they can be applied. During this time, they can be cancelled.
Users can then receive notice via email or text message when one of these Actions is broadcast. If they did not authorize it, then they can use the account recovery process to recover their account and retract the Action.
The required delay depends upon how sensitive an operation is. Paying for a coffee might have no delay and be irreversible in seconds, while buying a house may require a 72 hour clearing period. Transferring an entire account to new control may take up to 30 days. The exact delays are chosen by application developers and users.
FreedomTrain provides users with the ability to restore control of their account when keys are stolen. An account owner can use any owner key that was active in the last 30 days along with approval from their designated account recovery partner to reset the owner key on their account. The account recovery partner cannot reset control of the account without the help of the owner.
There is nothing for the hacker to gain by attempting to go through the recovery process because they already "control" the account. Furthermore, if they did go through the process, the recovery partner would likely demand identification and multi-factor authentication (phone and email). This would likely compromise the hacker or gain the hacker nothing in the process.
This process is also very different from a simple multi-signature arrangement. With a multi-signature transaction, another entity is made a party to every transaction that is executed. By contrast, with the recovery process the recovery partner is only a party to the recovery process and has no power over the day-to-day transactions. This dramatically reduces costs and legal liabilities for everyone involved.
Blockchain consensus depends upon deterministic (reproducible) behavior. This means all parallel execution must be free from the use of mutexes or other locking primitives. Without locks there must be some way to guarantee that transactions that may be executed in parallel do not create non-deterministic results.
When FreedomTrain parallel operation is enabled, it will be the job of the block producer to organize Action delivery into independent shards so that they can be evaluated in parallel. The schedule is the output of a block producer and will be deterministically executed, but the process for generating the schedule need not be deterministic. This means that block producers can utilize parallel algorithms to schedule transactions.
Part of parallel execution means that when a script generates a new Action it does not get delivered immediately, instead it is scheduled to be delivered in the next cycle. The reason it cannot be delivered immediately is because the receiver may be actively modifying its own state in another shard.
Minimizing Communication Latency Latency is the time it takes for one account to send an Action to another account and then receive a response. The goal is to enable two accounts to exchange Actions back and forth within a single block without having to wait 0.5 seconds between each Action. To enable this, the FreedomTrain software divides each block into cycles. Each cycle is divided into shards and each shard contains a list of transactions. Each transaction contains a set of Actions to be delivered. This structure can be visualized as a tree where alternating layers are processed sequentially and in parallel.
Region Cycles (sequential) Shards (parallel) Transactions (sequential) Actions (sequential) Receiver and Notified Accounts (parallel)
Transactions generated in one cycle can be delivered in any subsequent cycle or block. Block producers will keep adding cycles to a block until the maximum wall clock time has passed or there are no new generated transactions to deliver.
It is possible to use static analysis of a block to verify that within a given cycle no two shards contain transactions that modify the same account. So long as that invariant is maintained a block can be processed by running all shards in parallel.
Some accounts may be able to process an Action on a pass/fail basis without modifying their internal state. If this is the case, then these handlers can be executed in parallel so long as only read-only Action handlers for a particular account are included in one or more shards within a particular cycle.
Sometimes it is desirable to ensure that Actions are delivered to and accepted by multiple accounts atomically. In this case both Actions are placed in one transaction and both accounts will be assigned the same shard and the Actions applied sequentially.
Scaling blockchain technology necessitates that components are modular. Everyone should not have to run everything, especially if they only need to use a small subset of the applications.
An exchange application developer runs full nodes for the purpose of displaying the exchange state to its users. This exchange application has no need for the state associated with social media applications. FreedomTrain software allows any full node to pick any subset of applications to run. Actions delivered to other applications are safely ignored if your application never depends upon the state of another contract.
The FreedomTrain software cannot obligate block producers to deliver any Action to any other account. Each block producer makes their own subjective measurement of the computational complexity and time required to process a transaction. This applies whether a transaction is generated by a user or automatically by a smart contract.
On a launched blockchain adopting the FreedomTrain software, at a network level all transactions are billed a computational bandwidth cost based on the number of WASM instructions executed. However, each individual block producer using the software may calculate resource usage using their own algorithm and measurements. When a block producer concludes that a transaction or account has consumed a disproportionate amount of the computational capacity they simply reject the transaction when producing their own block; however, they will still process the transaction if other block producers consider it valid.
In general, so long as even 1 block producer considers a transaction as valid and under the resource usage limits then all other block producers will also accept it, but it may take up to 1 minute for the transaction to find that producer.
In some cases, a producer may create a block that includes transactions that are an order of magnitude outside of acceptable ranges. In this case the next block producer may opt to reject the block and the tie will be broken by the third producer. This is no different than what would happen if a large block caused network propagation delays. The community would notice a pattern of abuse and eventually remove votes from the rogue producer.
This subjective evaluation of computational cost frees the blockchain from having to precisely and deterministically measure how long something takes to run. With this design there is no need to precisely count instructions which dramatically increases opportunities for optimization without breaking consensus.
FreedomTrain Software supports deferred transactions that are scheduled to execute in the future. This enables computation to move to different shards and/or the creation of long-running processes that continuously schedule a continuance transaction.
A Context Free Action involves computations that depend only on transaction data, but not upon the blockchain state. Signature verification, for example, is a computation that requires only the transaction data and a signature to determine the public key that signed the transaction. This is one of the most expensive individual computations a blockchain must perform, but because this computation is context free it can be performed in parallel.
Context Free Actions are like other user Actions, except they lack access to the blockchain state to perform validation. Not only does this enable FreedomTrain to process all Context Free Actions such as signature verification in parallel, but more importantly, this enables generalized signature verification.
With support for Context Free Actions, scalability techniques such as Sharding, Raiden, Plasma, State Channels, and others become much more parallelizable and practical. This development enables efficient inter-blockchain communication and potentially unlimited scalability.
The FreedomTrain Platform is a platform for coordinating the delivery of authenticated messages (called Actions) to accounts. The details of scripting language and virtual machine are implementation specific details that are mostly independent from the design of the FreedomTrain technology. Any language or virtual machine that is deterministic and properly sandboxed with sufficient performance can be integrated with The FreedomTrain Platform API.
All Actions sent between accounts are defined by a schema which is part of the blockchain consensus state. This schema allows seamless conversion between binary and JSON representation of the Actions.
Database state is also defined using a similar schema. This ensures that all data stored by all applications is in a format that can be interpreted as human readable JSON but stored and manipulated with the efficiency of binary.
Generic Multi Index Database API
Developing smart contracts requires a defined database schema to track, store, and find data. Developers commonly need the same data sorted or indexed by multiple fields and to maintain consistency among all the indices.
To maximize parallelization opportunities and minimize the computational debt associated with regenerating application state from the transaction log, the FreedomTrain Platform separates validation logic into three sections:
Validating that an Action is internally consistent; Validating that all preconditions are valid; and Modifying the application state. Validating the internal consistency of a Action is read-only and requires no access to blockchain state. This means that it can be performed with maximum parallelism. Validating preconditions, such as required balance, is read-only and therefore can also benefit from parallelism. Only modification of application state requires write access and must be processed sequentially for each application.
Authentication is the read-only process of verifying that an Action can be applied. Application is actually doing the work. In real time both calculations are required to be performed, however once a transaction is included in the blockchain it is no longer necessary to perform the authentication operations.
Inter Blockchain Communication
FreedomTrain is designed to facilitate inter-blockchain communication. This is achieved by making it easy to generate proof of Action existence and proof of Action sequence. These proofs combined with an application architecture designed around Action passing enables the details of inter-blockchain communication and proof validation to be hidden from application developers, enabling high level abstractions to be presented to developers.
Merkle Proofs for Light Client Validation (LCV)
Integrating with other blockchains is much easier if clients do not need to process all transactions. An exchange only cares about transfers in and out of the exchange and nothing more. It is also be ideal if the exchange chain could utilize lightweight merkle proofs of deposit rather than having to trust its own block producers entirely. At the very least a chain's block producers would like to maintain the smallest possible overhead when synchronizing with another blockchain.
The goal of LCV is to enable the generation of relatively light-weight proof of existence that can be validated by anyone tracking a relatively light-weight data set. In this case the objective is to prove that a particular transaction was included in a particular block and that the block is included in the verified history of a particular blockchain.
Bitcoin supports validation of transactions assuming all nodes have access to the full history of block headers which amounts to 4MB of block headers per year. At 10 transactions per second, a valid proof requires about 512 bytes. This works well for a blockchain with a 10 minute block interval, but is no longer "light" for blockchains with a 0.5 second block interval.
The FreedomTrain Platform enables lightweight proofs for anyone who has any irreversible block header after the point in which the transaction was included. Using the hash-linked structure shown it is possible to prove the existence of any transaction with a proof less than 1024 bytes in size.
Given any block id for a block in the blockchain, and the headers a trusted irreversible block. It is possible to prove that the block is included in the blockchain. This proof takes ceil(log2(N)) digests for its path, where N is the number of blocks in the chain. Given a digest method of SHA256, you can prove the existence of any block in a chain which contains 100 million blocks in 864 bytes.
There is little incremental overhead associated with producing blocks with the proper hash-linking to enable these proofs which means there is no reason not to generate blocks this way.
When it comes time to validate proofs on other chains there are a wide variety of time/ space/ bandwidth optimizations that can be made. Tracking all block headers (420 MB/year) will keep proof sizes small. Tracking only recent headers can offer a trade off between minimal long-term storage and proof size. Alternatively, a blockchain can use a lazy evaluation approach where it remembers intermediate hashes of past proofs. New proofs only have to include links to the known sparse tree. The exact approach used will necessarily depend upon the percentage of foreign blocks that include transactions referenced by merkle proof.
After a certain density of interconnectedness, it becomes more efficient to simply have one chain contain the entire block history of another chain and eliminate the need for proofs all together. For performance reasons, it is ideal to minimize the frequency of inter-chain proofs.
When communicating with another outside blockchain, block producers must wait until there is 100% certainty that a transaction has been irreversibly confirmed by the other blockchain before accepting it as a valid input. Using anFreedomTrain software-based blockchain and DPOS with 0.5 second blocks and the addition of Byzantine Fault Tolerant irreversibility, this takes approximately 0.5 second. If any chain's block producers do not wait for irreversibility it would be like an exchange crediting a deposit that was later reversed and could impact the validity of the blockchain's consensus. The FreedomTrain Platform uses both DPOS and aBFT to provide rapid irreversibility.
When using merkle proofs from outside blockchains, there is a significant difference between knowing that all transactions processed are valid and knowing that no transactions have been skipped or omitted. While it is impossible to prove that all of the most recent transactions are known, it is possible to prove that there have been no gaps in the transaction history. The FreedomTrain Platform facilitates this by assigning a sequence number to every Action delivered to every account. A user can use these sequence numbers to prove that all Actions intended for a particular account have been processed and that they were processed in order.
The concept of Segregated Witness (SegWit) is that transaction signatures are not relevant after a transaction is immutably included in the blockchain. Once it is immutable the signature data can be pruned and everyone else can still derive the current state. Since signatures represent a large percentage of most transactions, SegWit represents a significant savings in disk usage and syncing time.
This same concept can apply to merkle proofs used for inter-blockchain communication. Once a proof is accepted and irreversibly logged into the blockchain, the 2KB of sha256 hashes used by the proof are no longer necessary to derive the proper blockchain state. In the case of inter-blockchain communication, this savings is 32x greater than the savings on normal signatures.
Another example of SegWit would be for Steem blog posts. Under this model a post would contain only the sha256(blog content) and the blog content would be in the segregated witness data. The block producer would verify that the content exists and has the given hash, but the blog content would not need to be stored in order to recover the current state from the blockchain log. This enables proof that the content was once known without having to store said content forever.
When using Douglass Applications and services be mindful that you are in alignment with the Beloved Community Pledge.
The Beloved Community Pledge
1. I recognize the humanity of the multitudes who are oppressed, persecuted, incarcerated and in struggle. 2. I declare that violence, poverty, racism, sexism, incarceration, surveillance, militarism and environmental destruction cannot persist. 3. I recognize that reparations and atonement are part of a needed healing process for shared humanity. 4. I pursue a world of freedom, spirituality and fulfillment for all. 5. I make change through nonviolence and radical love for all people and for our sacred planet. 6. I commit to the inspired change needed to create a more humanely just and coherent future. 7. I commit to becoming aware of those forces that seek to undermine the Beloved Community. 8. I will use (and build) only technology which is aligned with this pledge.
The Beloved Community License is an Nonviolent Software and Hardware License that has been created out of Love, Peace, and Purpose.