⛓️Blockchain Technology

POW+POS Hybrid Consensus Mechanism

POW Consensus Mechanism: Proof of Work

Proof of Work involves solving a complex problem, including the transactions you want to include in the block, to demonstrate that you have invested a certain amount of computational power in the process. Once a problem is solved, other members on the blockchain carefully inspect the solution. The first person to solve the computational problem submits the result to the blockchain to verify if the answer matches. If confirmed, the process of solving the problem starts again with a new block containing new transactions. The solved block is confirmed by others by including a reference to it in the next block.

POS Consensus Mechanism: Proof of Stake

In this approach, the difficulty of a problem one needs to solve depends on how much cryptocurrency one has staked, rather than gaining the right to validate a block through computational power. It's somewhat akin to buying lottery tickets: the more you buy, the higher your chances of winning. However, there's a difference – if you don't win, you don't lose your stake, although it may be locked for a period. In this case, those who hold a significant amount of tokens are interested in maintaining the reliability of the blockchain network since an unreliable network would render their tokens worthless. Hence, they only confirm valid transactions. In certain versions of PoS, if other parts of the network do not confirm your block, you may, in fact, lose your stakes (tokens).

TBC adopts the POW+POS hybrid consensus mechanism, a classic distribution mechanism that aligns well with both the proof-of-work principle favored by miners and the proof-of-stake principle embraced by token holders. After generating a new block through proof of work (PoW) where the block producer receives a 60% reward, it enters the PoS consensus voting phase. This allows holders to freely participate in voting and receive a system-assigned 30% reward. The remaining 10% goes into the community treasury, subject to community decisions.

This hybrid consensus method provides equal opportunities for both miners (proof-of-work advocates) and token holders (proof-of-stake advocates) to win blocks. Miners can increase their chances of winning by increasing their computational work, while token holders can increase their chances by holding more tokens. Each group has a 50% chance of winning.

Smart Contract Design

Smart contracts are specialized protocols designed to provide, verify, and enforce contracts. They enable us to execute transactions that are traceable, irreversible, and secure without the need for third parties. Smart contracts contain all the information about the transaction, and the result operation is only executed after meeting the requirements. The difference between smart contracts and traditional paper contracts is that smart contracts are generated by computers. Therefore, the code itself interprets the relevant obligations of the parties involved. In essence, smart contracts are digital contracts that, unless requirements are met, will not produce results.

TBC Game Finance Aggregation Launch Ecosystem Platform employs smart contracts for automated execution. The contract network and open-source authorization for various use cases are as follows:

Client Authorization*/ @Override
@Transactional

public TokenDto clientAuth(String username, String token, Game game)
{ Long gameId = game.getId();

if (!cacheService.match(CacheNames.CLIENT_TOKEN, username + gameId.toString(), token)) {
throwBadRequest(NO_AUTH);
}

DomainUser user = userService.findByName(username, true); gameLogonRepository.offLine(user.getId(), gameId); GameLogon logon = new GameLogon(); logon.setUserId(user.getId()); logon.setAccountId(user.getAccounts().iterator().next().getId()); logon.setGameId(gameId);
logon.setToken(DomainUtils.l币咚合约hars(username, 4) + DomainUtils.firstChars(token, 6));
logon.setCreateTime(new Date()); logon.setUpdateTime(logon.getCreateTime()); gameLogonRepository.save(logon);
TokenDto detail = new TokenDto(); detail.setUsername(username); detail.setToken(logon.getToken()); return detail;
}

/** * Initiate Payment after Authorization
*/ @Override
@Transactional
public TransResult createTrans(UserBrief user, Long gameId, TransDto request) {

Map<String, Account> accs = accountService.findAccountsIn(ImmutableList.of(request.getUsername(), request.getTo()));

Account from = accs.get(request.getUsername());

BigDecimal quantity = DomainUtils.typedMulti(request.getQuantity(), CoinType.GCN); if (from.getAmount().compareTo(quantity) < 0) throwBadRequest(LOW_AVAILABLE);
GameLogon fgl = gameLogonRepository.findByGameIdAndAccountIdAndTokenAndLogin(gameId, from.getId(), request.getToken(), true);

AccountTransaction trans = new AccountTransaction(); trans.setTransactionType(TransactionType.P2P);
if (DomainUtils.isNull(fgl)) {
if (!request.getUsername().equalsIgnoreCase(user.getUsername())) { logger.error(String.format("game#%d#trans#%s fail from#%s", gameId,
request.getTransNum(), request.getUsername()));
throwBadRequest(NO_PAYMENT_AUTH);

}
trans.setUserId(user.getId());

trans.setTransactionType(TransactionType.V2P); } else {
gameLogonRepository.outcome(fgl.getId(), quantity); trans.setUserId(fgl.getUserId());
}

Account to = accs.get(request.getTo()); GameLogon tgl =
gameLogonRepository.findByGameIdAndAccountIdAndTokenAndLogin(gameId, to.getId(), request.getToToken(), true);
if (DomainUtils.isNull(tgl)) {
if (!request.getTo().equalsIgnoreCase(user.getUsername())) { logger.error(String.format("game#%d#trans#%s fail to#%s", gameId,
request.getTransNum(), request.getTo()));
throwBadRequest(NO_PAYMENT_AUTH);
}
trans.setToUserId(user.getId());

trans.setTransactionType(TransactionType.P2V); repository.income(gameId, quantity);
} else {

gameLogonRepository.income(tgl.getId(), quantity); trans.setToUserId(tgl.getUserId()); repository.trade(gameId, quantity);
}
trans.setPreAmount(from.getAmount());
trans.setToPreAmount(to.getAmount()); trans.setQuantity(quantity); trans.setTransNum(request.getTransNum()); trans.setMemo(request.getMemo()); accountService.saveTransaction(trans);
logger.info(String.format("%d, from %s,%d, to %s", from.getId(), from.getAmount(), to.getId(), to.getAmount()));
accountService.outcome(from.getId(), quantity); accountService.income(to.getId(), quantity);
TransResult tr = new TransResult(from.getAmount().subtract(quantity), to.getAmount().add(quantity));

logger.info(String.format("%d, from %s,%d, to %s", from.getId(), tr.getAmount().toString(), to.getId(), tr.getToAmount().toString()));

return tr;

The smart contracts on the TBC platform are automated programs that execute without the need for manual intervention. Once deployed on the blockchain, smart contracts can autonomously execute predefined business logic and manage data.

Furthermore, smart contracts, operating on blockchain technology, ensure that once data is recorded on the blockchain, it becomes tamper-proof and immutable. This imparts a high level of security and trustworthiness to smart contracts.

Smart contracts are decentralized, devoid of centralized control entities. They are collectively maintained and managed by multiple nodes distributed across the network, making it a highly transparent, fair, and democratic system.

Data Encryption

The paramount requirement for a transaction platform is to ensure the security of data storage, management, and transactions. Leveraging a robust technical team, TBC employs a combination of software and hardware to create a financial-grade data security encryption solution, guaranteeing the safety of all on-chain data. In the realm of computing, where software vulnerabilities exist, relying solely on software for storage security is unreliable. TBC adopts a combination of software and hardware, implementing financial-grade security measures to ward off hackers.

Customized CPU: Laying the foundation from the lowest level of computer hardware

Independently designed a dedicated instruction set, requiring programs running on the host to be compiled using our proprietary compiler, rendering programs compiled with general-purpose compilers useless. This fundamentally eliminates any potential intrusion.

Financial-grade Cryptographic Module: Advanced key management technology

Primarily used to achieve encryption and decryption of application layer data on the host, validation of message source correctness, key management, etc. It is an effective physical tool for protecting the security level of financial data, featuring a sophisticated key management system. It provides truly random keys generated by a full hardware noise source (others provide pseudo-random keys); effectively prevents active attacks on communication channels; physically isolates sensitive information, rendering it unreadable; has self-destruct functionality in case of hardware disassembly; complies with the international standard FIPS 140-2 Level 3, offering high security.

Dedicated U-shield: Multiple security safeguards

The dedicated U-shield, along with cryptographic devices, achieves physical isolation of the user's core information and private key. The hardware chip has self-destruct functionality when disassembled. Without the user's security device, even stealing the hardware won't yield the private key, ensuring the security of user assets and eliminating the possibility of self-theft.