GODcoin Introduction
GODcoin is the totalitarian economy of the future endorsed by Christ!
Did you say endorsed by Christ!? Yes. Yes, I did.
Christ has returned in 2011 and he is here to bring the Kingdom of God while He judges the planet. A righteous King free from corruption that must be embraced by all! Once you're ready to swallow your pride and open yourself to Christ (or ignorantly reject Him and be left behind), help spread the word that the governments are suppressing (faith without deeds is dead)!
This project is the culmination of modern technology with the seemingly ancient monetary system of hard assets to provide a rock-solid foundation with Christ's endorsement. We utilize a Proof-of-Stake blockchain for digital token security and back it by gold and silver for stability. The blockchain contains two tokens, GOD (gold on demand) and SOD (silver on demand).
Dominion is not subtle!
Inquirers can learn more information here
http://godcoin.gold
http://godcoin.gold/whitepaper
Developers can find the source here
Team Intro
I'm the lead developer and Chief Technology Officer of GODcoin working alongside the other awesome individuals of the team. Others may know me as the creator of @steemdunk.
| Team | |
|---|---|
| Richard Ruff | Chief Executive Officer |
| Kelly Patrick | Chief Operating Officer |
| Joseph Monte | Chief Communications Officer |
| Samantha Kennedy | Chief Secretarial Officer |
| Jean Viete | Chief Marketing Officer |
| Corey DeFrancesco | Chief Productions Officer |
| Fred Desharnais | Chief Accountant Officer |
P2P
In the blockchain space, decentralized networks require a reliable peer-to-peer network. When dealing with fast paced block production systems, network efficiency must also be considered. Minimizing the effects of latency in message propagation is critical to ensure all consensus nodes remain in a consistent state.
Efficiency is in the form of low message redundancy. Any message redundancy adds additional overhead to the network. A high number of redundant messages signifies an inefficient use of the network.
A reliable network is in the form of minimizing message propagation latency, defined as the time it takes for the broadcast node to send a message to the entire network.
This is a collection of research notes largely inspired by Epidemic Broadcast Trees [1] and to gain a broader understanding of efficiently using the available resources. Work of evaluations and simulations can also be seen in [1].
Broadcast Strategies
There are a few strategies for deciding how to broadcast a message. We have eager pushing, lazy pushing, and polling. The best approach would be to use a hybrid of eager pushing and lazy eager pushing as described in [1]. By utilizing this hybrid methodology, we should be able to effectively minimize latency for message propagation.
Using eager push
The node broadcasts to its neighboring peers. These peers then propagate the message to their neighbors until every node has the message.
Using lazy push
The node broadcasts a message header to its neighboring peers. The peer can then request the full payload from the node that sent the header. Once the payload is received, it can then broadcast the message header to its neighboring peers until every node has the message.
Using the hybrid approach
All nodes have an eager push set and a lazy push set. Initially, all nodes are placed into the eager push set. Overtime both sets will be populated as messages are being broadcasted.
When a node receives a message for the first time, its sender will remain in the eager push strategy set. Upon receiving a duplicate message, its sender will be moved to the lazy push set, likewise the sender will also move the receiving node to the lazy push set. As this happens, an optimal tree will be created that minimizes latency.
When a node receives a message header, it will start an expiry timer while waiting for the eager push from its neighbor. If the timer limit is reached, the node will request the full message and the node and its sender will be moved to the eager push set. This self-healing property allows the tree to remain with optimal latency.
Detecting Duplicate Messages
In a blockchain network, the message identifier can be a hash of the transaction or the block hash depending on what is being broadcasted. This will make pruning unnecessary as we will see in the next section.
Message Pruning
Traditionally, messages will be pruned given specific parameters, depending on application. However, in a blockchain network, either the block or transaction being propagated. These types of messages are stored permanently in the blockchain, making it easy to detect duplicate messages and unnecessary to prune.
References
[1] http://asc.di.fct.unl.pt/~jleitao/pdf/srds07-leitao.pdf
