This document has been produced for reference and education purposes only. Nothing contained in this document is designed to assist with due diligence, acquisition, or serve as any kind of investment prospectus. In no way does this document constitute any kind of road map, project plan, or certification as to the exact technology being produced or designed by the company. From time to time, as with all technical projects, things may need to change, the company and its development team have no control over such factors.
Aside of the above, all technical information contained within this document is accurate at the time of writing. The company reserves the right to amend the document along with the contents contained within. No reliance should be placed on this document to guarantee technical deployment, development, or availability of any of Ceek’s services.
This document must not be reproduced or distributed without the express written permission of CEEK GLOBAL INNOVATIONS or any of its subsidiaries.
Introduction
CEEK GLOBAL INNOVATIONS(CEEK) is committed to delivering its customers the best quality VR streaming from any event in the world to any location on the globe. High quality content delivery is resource intensive and requires a distributed set of connected powerful computers to relay near-instant streams to all audiences. Enabled by groundbreaking blockchain technology Ceek is building a decentralized network of masternodes to ensure the best possible VR experience.
Masternodes are powerful servers independently operated by Ceek enthusiasts that are looking to both enable the network and be rewarded for their efforts. The rise of blockchain technology enables Ceek to create such a distributed content delivery network that is maintained by people who have a vested interest in its successful operation. The Ceek masternode network will ensure reliable content delivery that is secure, protected, censorship resistant and throttle-proof.
What are masternodes?
A masternode is a server that offers utility to a distributed network. The concept is specific to the blockchain space and is meant to represent the decentralized counterpart of the consolidated model employed by centralized solutions today.
Traditional infrastructure relies on cloud hosted servers and network equipment, which are centralized in big data centers across the globe and offer good performance and availability at moderate costs and security levels.
The masternode network offers the same performance and arguably better availability, as there is truly no central point of failure, while the cryptographically secured infrastructure ensures the highest level of security, privacy and censorship resistance.
In order for the network to be secured and protected from malicious actors, masternodes operators are required to vest interest by locking up -or staking -a considerable amount of tokens for a long period of time, thus aligning their private interest with that of the network itself. Acting maliciously can result in seizing of a portion or of all the locked tokens.
The network rewards the operators with a periodic distribution of tokens that is proportional to the utility provided. These rewards are usually proportional to the amount of locked tokens and performance & availability of the servers.
Ceek has decided in favor of distributing its future content via such a decentralized network, so as to offer the best possible quality at the lowest price point and highest level of trust.
Ceek Masternodes Explained
The Ceek distributed network will be initially comprised of 1000 masternodes. These servers will be used to relay high quality VR content to Ceek audiences throughout the globe. They will require a fast CPU and sufficient memory and bandwidth to process and distribute the data stream as fast and efficient as possible.
To protect the best interests of Ceek customers and the Ceek network itself, masternode operators will be required to stake CEEK tokens as collateral. The staking mechanism is intended to both protect the Ceek network from malicious actors and also as an incentive mechanism for operators who get rewarded for running nodes.
There will be five grades of masternodes, serving the same purpose but granting increasingly higher rewards with the amount of tokens staked.
Grade 1 Masternodes will require {{gradeOptions[0].tokensStaked | number : 0}} CEEK tokens to be staked, offering a reward of {{gradeOptions[0].monthlyReward | number : 0}} CEEK tokens per month.
Grade requirements increase in {{(gradeOptions[0].tokensStaked - gradeOptions[0].tokensStaked) | number : 0}} CEEK token increments, with Grade 5 requiring {{ gradeOptions[4].tokensStaked }} CEEK tokens.
Rewards will be awarded for all masternodes that meet the uptime requirement of 98.5% over a period of three months. Availability is measured by periodically challenging each node to perform a Ceek-specific computation. Failure to do so marks the node as unavailable for that respective period of time and degrades its availability by 0.5%.
To secure Ceek’s long term vision for the future of VR entertainment masternodes will be incentivized to commit their support for long period of times. Thus nodes can be committed for at least 1 year, with rewards increasing by 5% for every additional year of commitment, up to 3 years and 10% bonus.
Nodes can be created, deleted and transferred at any time. When deleting a node, the outstanding rewards will be claimed at the end of the reward cycle. If the node is deleted before the committed time period, the long term bonus will not be awarded. Existing nodes can only be transferred to other node operators who have the option to bid for taking over a masternode from another owner. In case there is no interest in taking a node over, it will be deleted and the respective rewards will be claimed by the original owner.
The table below indicates the necessary tokens to be staked per masternode grade and the rewards, assuming 100% uptime throughout the reward periods.
Node grade |
Tokens staked |
Monthly rewards |
Quarter rewards |
1 year reward |
2 years reward |
3 years reward |
{{grade.grade}} |
{{grade.tokensStaked | number: 0}} |
{{grade.monthlyReward | number: 0}} |
{{grade.quarterReward | number: 0}} |
{{grade.yearReward1 | number: 0}} |
{{grade.yearReward2 | number: 0}} |
{{grade.yearReward3 | number: 0}} |
Ceek masternodes grades and rewards calculator
Building a masternode
Node operators can run servers that they either own & host themselves or rent out from cloud providers such as Amazon or Digital Ocean. Global coverage for the Ceek network is important so geographic distribution is encouraged.
Ceek masternodes will require a Linux operating system and a physical or virtual server with the following minimum configuration:
- 2 vCPUs
- 4GB of RAM
- 80GB storage
- 4TB traffic
Bring up a cluster
A walkthrough of setting up a more realistic cluster is here.
Let's bring up 2 more nodes, so we have a 3-node cluster. That way we can tolerate the failure of 1 node:
$GOPATH/bin/hraftd -id node1 -haddr :11001 -raddr :12001 -join :11000 ~/node1
$GOPATH/bin/hraftd -id node2 -haddr :11002 -raddr :12002 -join :11000 ~/node2
This example shows each hraftd node running on the same host, so each node must listen on different ports. This would not be necessary if each node running on a different host.
This tells each new node to join the existing node. Once joined, each node now knows about the key:
curl -XGET localhost:11000/key/user1
curl -XGET localhost:11001/key/user1
curl -XGET localhost:11002/key/user1
Furthermore, you can add a second key:
curl -XPOST localhost:11000/key -d '{"user1": "ceek"}'
Confirm that the new key has been set like so:
curl -XGET localhost:11000/key/user1
curl -XGET localhost:11001/key/user1
curl -XGET localhost:11002/key/user1
Stale reads
Because any node will answer a GET request, and nodes may "fall behind" updates, stale reads are possible. Again, hraftd is a simple program, for the purpose of demonstrating a distributed key-value store. If you are particularly interested in learning more about issue, you should check out rqlite. rqlite allows the client to control read consistency, allowing the client to trade off read-responsiveness and correctness.
Read-consistency support could be ported to hraftd if necessary.
Tolerating failure
Kill the leader process and watch one of the other nodes be elected leader. The keys are still available for query on the other nodes, and you can set keys on the new leader. Furthermore, when the first node is restarted, it will rejoin the cluster and learn about any updates that occurred while it was down.
A 3-node cluster can tolerate the failure of a single node, but a 5-node cluster can tolerate the failure of two nodes. But 5-node clusters require that the leader contact a larger number of nodes before any change e.g. setting a key's value, can be considered committed.
Leader-forwarding
Automatically forwarding requests to set keys to the current leader is not implemented. The client must always send requests to change a key to the leader or an error will be returned.
Delegating Coins
Each masternode needs to be registered to a unique private key on the BSC network. The associated wallet needs to contain the required amount of CEEK tokens upon creation, corresponding to the desired node grade, as mentioned in the previous sections. Any actions regarding the master node, such as claiming profits, transferring or deleting it, have to be executed with the corresponding private key.
Delegating coins to a master node is done by executing a smart contract.
Please consider that claiming back the coins associated with a master node is only possible at the end of the reward cycles, so a delay is to be anticipated.
For the purpose of transparency, we include below the variables and events associated with the Masternodes smart contract.
stakeSize// how many tokens required to run masternode grade 1
maxGrade// max allowed masternode grade
masternodesLimit // how many masternodes allowed
expectedRewardPerMasternode // Expected reward per grade 1 masternode per period. Set by admin, just for information purpose (calculator)
clusterHead // Address of our cluster head. Cluster head server belongs to CEEK an submits information about which masternode is active and which is not.
masternodesCount // total masternodes count
masternodesCountActive // active masternodes count
Following variables used for rewards process
rewardsSending// rewards sending in progress
rewardsTotalStake // How many tokens locked by all active masternodes
rewardsBalance // rewards balance which left to distribute during a distribution cycle
rewardsToDistribute // How many tokens to distribute during a distribution cycle
Events
MasternodeCreated(address indexed from, uint256 stake);
MasternodeDeleted(address indexed holder);
MasternodeTransferred(address indexed sender, address indexed receiver, uint256 amount);
RewardAdded(address indexed from, uint256 amount);
RewardCredited(address indexed holder, uint256 reward, uint256 oldBalance, uint256 newBalance);
RewardWithdrawn(address indexed holder, uint256 amount);
RewardDistributionFinished();
RewardDistributionStarted(uint256 rewardsBalance, uint256 rewardsTotalStake);
ClusterHeadChanged(address indexed previousHead, address indexed newHead);
MasternodeActivityChanged(address indexed masternodeAddress, bool previousIsActive, bool isActive);
ExpectedREwardPerMasternodeChanged(uint256 expectedRewardPerMasternode, uint256 _expectedRewardPerMasternode);
LockingPeriodUpdated(uint256 periodInMonth, bool isActiveOld, bool isActiveNew);
MasternodeQueuedForDeletion(address holder);
Functions for user (masternode holders)
Create masternode
Requirements:
- Rewards Sending: No
- Allowed looking period
- Have free slots
Claim Rewards
Requirements:
- Rewards Sending: No
- Positive balance
- Masternode exists
Stop Masternode
Requirements:
- Rewards Sending: No
- Masternode exists
- Locked period finished
Transfer Masternode
Requirements:
- Rewards Sending: No
- Masternode exists
- Receiver is a valid BSC address
CEEK company functions
Change Masternode Status (by clusterHead)
Requirements:
- new status differs from old
Crediting rewards
Requirements:
- Have non-processed masternodes
Ceek ERC20 Wallet
In Ceek network your identity is a pair of private and public keys stored on your computer (or stored in some other place you have access to). A wallet is nothing but a key pair. In the construction of wallet a new key pair is generated with ECDSA which is based on elliptic curves. A private key is generated using the curve, and a public key is generated from the private key. One thing to notice: in elliptic curve based algorithms, public keys are points on a curve. This is a public key is a combination of X, Y coordinates.
If you want to send coins to someone, you need to know their address. But addresses (despite being unique) are not something that identifies you as the owner of a “wallet”. In fact, such addresses are a human-readable representation of public keys. The address generation algorithm utilizes a combination of open algorithms that take a public key and returns real Base58-based address.
Using Ceek network in conjunction with the ERC721 protocol
This protocol implies the provision of a guaranteed right to use a graphic, multimedia information to any person while not providing any tool to actually close the information file for any use by third parties. Due to its specific nature of development and architecture, the Ceek software and network complex has all the necessary capabilities to provide the ERC721 audience with the necessary set of tools for manipulating access rights to information as a guaranteed owner. Access rights can be very diverse:
- Full access to content;
- Partial access to content;
- Full access for a limited period of time;
- Full access to a limited number of people, etc.
To date, ERC721 absolutely does not exclude the possibility of substituting files or file content for a hash belonging to one or another user owning a hash of the file. This Ceek has all the necessary facilities to provide the basic tools for guaranteed ownership of the file as an unquestionable right to own information.
Namely:
- Ceek ensures that the specified hash stored in the ERC721 account can indicate and grant ownership to the only existing file, and any modification will result in the owner losing the rights to the specified file;
- Ceek provides the necessary tool to restrict the rights of access to the file by third parties;
- Ceek guarantees the owner of the file its full concealment, integrity, and also anonymity if necessary;
Given the fact that the standard ERC721 is currently a global brand it gives the opportunity to believe that representing of this functionality on the part of Ceek guarantees a sufficiently high competitiveness and commercial benefits.
