The mission of GCGC is to integrate disruptive technology into finance, e-commerce and mining to make business more inclusive, seamless and accessible. The GCGC blockchain will drive the adoption of technology in international trade, commerce and financial services by making it better, faster and easier.
The GCGC Protocol is a flexible and efficient blockchain service designed for businesses, enterprises, and governments. It is supported by an open system architecture and a workflow engine that allow ease of integration and rapid development. By focusing the design on the concept of an open system architecture with a workflow engine, the GCGC Protocol can allow multiple businesses and even governments to connect quickly and flexibly into the GCGC ecosystem.
The open system architecture makes adding, upgrading and swapping of modular units easy and thus, the GCGC Protocol can be efficiently integrated with enterprise solutions to drive lower costs in transactions, connectivity on a global scale, and greater adoption by its ability to be tailored to specific industry needs.
1. DESIGN PRINCIPLES OF THE GCGC PROTOCOL
USER FRIENDLY
- HIGH INTEROPERABILITY
Through various collaborations with different industry partners, GCGC has created several reliable blockchain solutions that are better, faster and easier to use within its ecosystem. Being supported by open system architecture and a workflow engine, the GCGC Protocol can work with other products or systems, at present or in the future, in either implementation or access, without any restrictions.
- SECURITY & RELIABILITY
The GCGC Protocol is accessed via the Federation System which allows security principle identities and attributes to be shared across trust boundaries according to established policies. It is concerned with where the user’s credentials are stored and only allows trusted third-parties and can authenticate against those credentials without actually seeing them.
- OPEN INTEGRATION
Through the use of open system architecture and a workflow engine, the GCGC Protocol allows all partners in their ecosystem to integrate their data and networks as well as other existing enterprises’ solutions to bring more convenience, value, and possibilities to them.
2. GCGC BLOCKCHAIN
The GCGC blockchain combines the advantages of different protocols into one. We have implemented a permissioned hybridization model for the blockchain.
As other protocols and networks utilise a consensus mechanism called Proof-of-Work (PoW) where the security of the network depends on the collective hash power of the network, a group of malicious entities could easily attack smaller networks and change the blockchain while still playing by the rules of its protocol. This malicious group would only need a larger hash power (51%) as compared to the other stakeholders in the network to achieve this. Unlike Bitcoin, a small network is not massively distributed, and hence the hash power is not significant enough to provide any protection.
PBFT/POW HYBRID
A PoW/pBFT (Practical Byzantine Fault Tolerance)-like consensus protocol is a solution to the problem as it replaces the reliance on PoW by using endorsements. Fundamentally, a new block can be added to the chain after having been agreed to and endorsed by a given number of known peers. The chain can then be validated by checking the validity of the endorsement signatures.
There are 2 tiers of participants in such a network: External clients (such as software wallets and exchanges), who only have permission to submit transactions and audit the blockchain; And known peers, which would have the permission to create, endorse and commit blocks to the chain.
BENEFITS OF PBFT/POW HYBRID
The design of the pBFT/ PoW Hybrid will not only protect the network from the above-mentioned attacks, but it will also allow for a much higher transaction throughput.
Transactions per second will only be limited by block size and network communication speed. The practical confirmation time would also be similar to that of VISA’s than of Bitcoin’s. While the PoW chains require time and have difficulty confirming transactions, GCGC Protocol relies solely on endorsements.
THE LIFE CYCLE OF A BLOCK IN AN ENDORSEMENT MODEL
To understand the model, it is beneficial to look at the life cycle of each block as it goes from creation to inclusion in the blockchain ecosystem.
In the current PoW system, the life cycle of the block is relatively simple. It is created, mined and distributed to all other peers. However, the hybrid model’s method of consensus is slightly more complex.
Each block in this model will go through the following three stages:
At the Proposal stage, the block is created, mined (at a low difficulty), and signed by the orderer. After
this, the block is distributed to all other known peers (called endorsers).
At the Endorsement stage, each endorser will check whether the proposed block fully complies with the given set of rules and the latest chain state. If it is valid, it will then return to the orderer and be endorsed.
Endorsement [64]byte = signed(proposal_block_hash)
At the Commit stage, the orderer waits for the proposed block to receive at least X number of valid endorsements before combining with the Endorsement signatures and creating the final hash.
X >= number_of_peers/2
Final_hash [64]byte = sha256(endorsements + proposal_hash)
This completed block is then distributed to all peers so that they can update their local state of the blockchain. At this point, all transactions in the blockchain can be considered fully processed and valid.
It is important to note that each peer in the network, including the orderer, must be polymorphic. This is to ensure that in the event where an orderer is malicious or faulty, other peers in the network can adopt the role of orderer to prevent any downtime.
LEGACY PROTECTION USING POW
On the surface, the endorsement model would work without any PoW mining and consensus can be reached even with X-1 faulty nodes. However, given a situation with X + 1 faulty/malicious node, the history of the blockchain could theoretically be rewritten at a hyper-fast rate using a ‘consolidation’ attack (where networking time would be eliminated). To protect the network against such attacks, PoW mining of the blocks at a low difficulty could be added to act as a barrier against such attacks without significantly slowing down the throughput of the blockchain.
UPDATES BLOCKCHAIN PROTOCOL
The general transaction processing protocol will remain the same. With the combination of both consensus mechanisms, extra rules and exceptions will be added for the proposal, endorsement, and commit stages.
Proposal hash is added where it will be the hash of all transactional data, timestamp, block notes, the public key of the known orderer, and nonce. This hash (BLAKE2B) must be the solution to the target difficulty.
An array of endorsement signatures will not be included in the proposal hash. Each endorsement signature will be digitally signed proposal hash with Elliptic Curve Digital Signature Algorithm (ECDSA).
Block hash is the hash of the proposal hash and the endorsements which use BLAKE2B.
Orderer signature is the signed block hash matching the public key that first signed the proposal using ECDSA. All signatures must come from a known and non-blacklisted Peer. The previous hash included in the proposal block will reference the last block’s final hash.
KNOWN PEERS & BLACKLIST
For now, this is a permissioned, private blockchain. Known peers are trusted nodes that interact with one another and have the function of validating and appending the blockchain. A list of known peers is merely a collection of public keys, which are publicly available.
Initially, the note in the genesis block should contain a list of all known peers. Signatures used on/within the block will be checked to see if they match one of these known peers. This prevents any unknown and untrusted party from participating.
A mechanism may be adapted to allow known peers to be added at a later point in time to increase the practical fault tolerance/flexibility of the network. However, this mechanism itself must be secured. If it is improperly handled, it could become a single point of failure. There are a few options for adding and blacklisting peers, which may be used exclusively or interchangeably.
Voting — A new known peer is voted in and its inclusion in a block requires X endorsements. This mechanism can also work for blacklisting a peer. We would recommend this method.
Centralized protocol update — peers can be hardcoded into the protocol and distributed through a secure centralized mechanism.
FUTURE UPDATE FLEXIBILITY
Updates to the protocol can be distributed through manual software changes, much like Bitcoin core. As long as you keep an accurate account of the block indexes (by the method of inclusion in proposal_hash), you can make the necessary updates to the protocol without invalidating the chain up to that point.
Although it is currently a permissioned blockchain, there is potential to work on an open and decentralized variant in the near future.
PROS AND CONS
Although increased security at a smaller operational scale and higher throughput are the targeted benefits, this network offers other significant advantages, which are the side effects of centralization:
No need for transaction fees as rewards. The only reason for transaction fees is spam prevention, (which can be prevented through a transaction PoW system), or to generate revenue from the network’s operation.
However, the model is not without its faults. Arguably, it is less secure than a massively distributed PoW network like Bitcoin. This is a very centralized model as known peers control the mechanisms of creating and committing blocks. Centralization is always a security concern, although the distrib- uted and polymorphic nature of the network’s peers, mitigates some of that concern.
ATTACKS
Endorser Corruption — If an Endorser is individually hacked and their private key is stolen, the hacker can approve false blocks or reject valid blocks. However, the network would still run without a problem, as the majority of peers are still honest, and those faulty blocks will not be added. Once the faulty node is detected, we can blacklist its public key from the list of known peers and replace it with a new one.
Consolidation Attack — This is a theoretical attack, whereby a malicious entity gains the private keys of at least X known peers. They could consolidate/unify the public keys to a single local environment and recreate the blockchain from any point, with new data, and without any network delay. The exclusion of any network latency would mean that more blocks could be recreated within a given time. However, the inclusion of the hybrid’s PoW is a significant barrier to altering history. This protection can be estimated as a function of the average hash strength of the network and the number of blocks changed.
Denial of service (DoS) attacks — This primarily targets the orderer. Sending ‘spam’ message to block a peer’s network connection and prevent them from engaging with the network. Considering that each peer machine will have a list of all other peers, if one peer is attacked then there is a high chance for a DoS attack. However, such an attack will halt the blockchain rather than change the data within it.
SUMMARY
In summary, private networks must take advantage of their known peers to achieve some level of security. This hybridization is a step in the right direction which replaces the demand for proof of work. However, we have not outlined how a new orderer could be chosen, this remains a vulnera- bility whereby an attack on a single peer could halt the network.
In the future adoption of the Tendermint consensus, the method will lead to even greater gains in security. Tendermint assists in securely and consistently replicating an application on many machines. By securely, we mean that Tendermint works even if up to 1/3 of machines fail in arbitrary ways. By consistently, we mean that every non-faulty machine sees the same transaction log and computes the same state. Secure and consistent replication is a fundamental problem in distributed systems. Thus ensuring the performance of the GCGC Protocol.
OTHER NETWORK PROTOCOL COMPARISONS
GCGC Blockchain vs Bitcoin vs Ethereum vs Litecoin
GCGC Blockchain allows for faster transaction confirmation time at lower transaction cost in comparison to the other top traded coins.
3. TECH STACK DESIGN
SYSTEM ARCHITECTURE
The GCGC Protocol is mainly composed of core components such as the Federation System, the Exchange and Blockchain Systems, the Exchange and Blockchain Bots and the Databases. The figure below illustrates the system architecture of the GCGC Protocol network:
FEDERATION SYSTEM
The Federation System eliminates the requirement of passwords as it knows the usernames for users in each application and presents the application with a token. Because of the trust between the two systems, the target application accepts this token and authenticates the user. The benefit of Federation is security and authentication into both on-premise and cloud applications.
EXCHANGE SYSTEM AND BOT
The Exchange System is a digital exchange platform for the trading of cryptocurrencies or digital currencies.
BLOCKCHAIN SYSTEM & BOT
The blockchain system is customised based on the customer’s choice of modules and components. The figure below illustrates the modules and components that can be added to the blockchain solution for the client.
This modular approach enables us to develop different types of components and to change individual components without affecting the rest of the system. This helps us to create a different workflow and integrates to existing applications to build distributed ledger solutions well-suited to different requirements for industry use cases.
EXCHANGE, FEDERATION & REPORTING DATABASES
The databases attached to the Federation, Exchange and Blockchain System stores configuration metadata and a hash of the document or other media content with blockchain business logic. These data and documents can be easily retrieved by directly accessing the database by developers and other users for reporting, analytics, or other data-centric integrations.
TECHNOLOGY INFRASTRUCTURE
TECHNOLOGIES INVOLVED
The platform utilizes the latest technological innovations. We provide decentralized computation and record storage on top of blockchain foundations. We also provide additional capabilities by utilizing the best industry practices in security, performance, and reliability.
The platform has edge nodes deployed around the world for the fastest global data delivery with the ability to conduct blockchain operations (confirmation time) within 1 second (comparing to Bitcoin’s 78minutes) at a 20,000 per second concurrent transaction speed (comparing to Bitcoin’s 7 per second).
Security is the highest priority in our solution. With that, we only utilize world-class SOC-1 accredited computation mediums, where datacentre locations are only disclosed to approved personnel. We also ensure datacentres maintain ISO 27001:2013, IRAP, and PCI compliance.
GCGC BLOCKCHAIN PROTOCOL
The platform adopts an API first methodology where all capabilities and operations are available as APIs. This fully embraces the multi-device, multi-system world we are living in today.
Any user can connect to the platform using their mobile devices, as well as various desktop browsers. Developers can also extend the native offerings by building additional specialized devices, such as voting machines in fan events, payment modules at retail, etc. This APIs first methodology extends the platform to limitless possibilities and provides rich and easy-to-use APIs that support interoperability with other systems.
A well-defined set of APIs enables external clients and applications to interface quickly and easily with the GCGC ecosystem. These APIs support the growth of a rich and holistic ecosystem and help blockchain and distributed ledger technologies proliferate across a wide range of industries and businesses.
The marketplace is entirely token driven where all the economies will be based on tokens rather than fiat, this provides extremely fast transactional settlement capabilities and eliminates expensive external transactional costs.
Having a 20,000 per second concurrent processing speed allows the token to be utilized as a real-time environment, enabling massive adoption and online media campaigns to be conducted. This is where the GCGC Protocol triumphs over traditional systems and blockchain systems as these systems tend to not be able to meet this demand. The token is protected by SHA256 encryption which makes it impossible to reverse engineer.
GEOGRAPHIC SPREAD
The system is deployed on servers across 20 different regions across the globe. Each geographic region listed below contains two sub-regions.
Each server is identical to each other and is configured to maximise computation power to process complex mathematical problems.
HIGH AVAILABILITY
The network is designed for automatic scaling, allowing the network to increase 100% in capacity according to demand. The system is also able to withstand catastrophic failures with the ability to operate with 50% of the current nodes unavailable.
SYSTEMS REQUIREMENTS
Each full node will require full Internet connectivity, a minimum internet connectivity speed (50KB/s) and a storage space of 20GB.
ALTERNATIVE CONFIGURATIONS
4. WEB APPLICATION SECURITY POLICY
OVERVIEW
Web application vulnerabilities are weaknesses or misconfigurations in a web application code that allows an attacker to gain some level of control of the site and possibly the hosting server. It is critical that any web application be assessed for vulnerabilities and any vulnerabilities be remediated prior to production deployment.
PURPOSE
The purpose of this policy is to define web application security assessments within the GCGC ecosystem. The web application assessment is designed to test the security of a web application prior to use by internal employees or your customers. It is also used to continually monitor website security, helping to identify and protect against vulnerabilities or misconfigurations within web applications which are currently in use. Discovery and subsequent mitigation of these issues will limit the attack surface of GCGC services available both internally and externally as well as satisfy compliance with any relevant policies in place.
SCOPE
This policy covers all web application security assessments requested by any individual, group or department for the purposes of maintaining the security posture, compliance, risk management, and change control of technologies in use.
All web application security assessments will be performed by delegated security personnel either employed or contracted by GCGC. All findings are considered confidential and are to be distributed to persons on a “need to know” basis. Distribution of any findings outside of GCGC is strictly prohibited unless approved by the Chief Information Officer.
Any relationships within multi-tiered applications found during the scoping phase will be included in the assessment unless explicitly limited. Limitations and subsequent justification will be documented prior to the start of the assessment.
POLICY
Web applications are subject to security assessments based on the following criteria:
All security issues that are discovered during assessments must be mitigated based upon the following risk levels. The Risk Levels are based on the OWASP Risk Rating Methodology. Remediation validation testing will be required to validate fix and/or mitigation strategies for any discovered issues of Medium risk level or greater.
The following security assessment levels shall be established by the InfoSec organization or other designated organization that will be performing the assessments.
The current approved web application security assessment tools which will be used for testing are:
Other tools and/or techniques may be used depending upon what is found in the default assessment and the need to determine validity and risk are subject to the discretion of the Security Engineering team.
POLICY COMPLIANCE
An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
Web application assessments are a requirement of the change control process and are required to adhere to this policy unless found to be exempt. All application releases must pass through the change control process. Any web applications that do not adhere to this policy may be taken offline until such time that a formal assessment can be performed at the discretion of the Chief Information Officer.
SECURITY INFRASTRUCTURE
Two Factor Authentication (2FA)
We use Multi-Factor Authentication to protect the user on top of the standard login information. Our MFA uses RSA algorithms to generate a temporary token where it is then pushed to the user via SMS or Authenticator device. The user has a limited time to respond to the token security challenge. Failure to do so repeatedly will result in account suspension.
KYC (Know your customer)
Our identity system allows custom workflows around complex KYC/AML compliance processes which caters for various jurisdiction requirements. Especially with the recent introduction of GDPR, our system is compliant with global identity regulations, especially in the finance industry. We store sensitive data with encryption-at-rest and a unique decryption key per identity document which prevents unauthorized access and potential misuse.
AES Encryption Prevention
All data stored within our system are encrypted at rest. Our authentication uses Salted Challenge Response Authentication Mechanism with the SHA1 algorithm. All transportation is under mandatory SSL. All backups and data utilize AES256 encryption. We take data security very seriously.
Anti CSRF Token
Our systems utilise JSON Web Token which is an improvement of the CSRF methodology by providing an encryption per user, per session as opposed to a public token. JWT by Auth0 is the current industry leader in security space that is widely adopted by the cutting-edge Silicon Valley companies. It is a modern methodology that supports both APP as well as Web interfaces.
XSS Clean
We use NoSQL for centralised data store requirements. The modules we use for NoSQL access protects the system with SQL injection. We also conduct peer code reviews, third party security audits to ensure our codebase is free from issues of potential third-party code injection. We triple protect our application. Our Web Application Firewall (Sqreen) utilise AI to block code injections, DDoS, and the latest security vulnerabilities. Our network layer firewall (Cloudflare) blocks DDoS and other attacks. And our data centers are world-class SOC1 accredited, with ISO27001:2013, IRAP, and PCI compliance accreditation.
Secure HTTP Headers
Our system forces HTTPS only communications. We utilise HTTP Strict Transport Security to prevent CNAME redirects, disable Max-Age, disable preloading and prevent no-sniffing. We also force TLS1.3.
Software / System details disclosure
Found PHP version on HTTP Response. Malicious users can know system details for find vulnerability from a public source or research private exploit. By not utilising a technology which renders client page on the server, we do not suffer the technology vulnerability faced by PHP, ASP, and similar technologies. Our server is triple protected as described above and is able to handle high volume with low latency. Our latest performance report showed that we rendered 18 million responses with an average time of 12ms, with 100% uptime, excellent performance in any web-based technology.
Prevention of Malicious File Uploading Process
Our system does not allow malicious file processing where the file upload bypasses the server entirely, and uploads to the file storage directly.
Mail ID encryption
Implementation of email encryption method. So, hackers cannot decrypt/edit our email address using our DB. All emails should have a layer of security. We utilize SendGrid for outbound email, it offers the latest authenticity and security practices. We configure DKIM and SPF to ensure mail delivery and security. We then add DNS based authenticity to ensure mail genuineness.
Session expiry with user re-login
Our tokens have a session expiry time, allowing sliding window authentication as well as time-based expiry.
Device based tracking (IP Address, MAC Address/ Mobile device ID, User)
We comply with GDPR and privacy policies imposed by Australia, UK and HK governments. MAC address-based tracking is illegal in certain jurisdictions. We only track and store information where we have the rights to do so. We also utilize third party to provide analytics information.
Device based or IP based Admin panel login
Our admin portal is IP restricted and role restricted. Hidden mailing system implementation for the site owner to know the present login credentials for Admin panel, in case any hacker changes it internally or externally. Our credentials are encrypted and not stored in plain text. Any changes to user credentials will trigger an email to the user. This security practice is not only reserved for the administrator but available to all users
Apart from the above, we could also implement the usage of 2 different servers where one is used to store the assets, source codes & sensitive data and the other is used to store the uploaded files. Our systems architecture consists of processing servers, blockchain infrastructure, data storage, and file storage, all residing on different physical infrastructure. All within a VPN which can be accessed externally.
For more details about the GCGC project, please visit the Official Website: https://www.gcgc.one
GCGC Officials:
Twitter: https://twitter.com/GCGCcommunity
Facebook: https://www.facebook.com/GCGCcommunity
LinkedIn: https://www.linkedin.com/company/gcgc-investments-limited
Telegram: https://t.me/gcgccommunity
Medium: https://gcgccommunity.medium.com
Wechat:
