Be pleased to give update that the hardfork codes for the old PLAY 2.0 Network have been ready and is now undertesting, and the token part of the new Dapp is almost finished, and now been testing on Ethereum kovan network.
There are some new changes to the migration roadmap and solution. The old solution uses oraclize.it to query and check the signature. but it was found that there are two different types of balances that required to be migrate: the accout balance and the address balance. It is not very complex for the accout balance to migrate, but for the address balance, there are some huge issue with user experience for normal users, because every account could have a lot of addresses, which means user need to do a lot of operations to finish the operation. So the solution was changed to a new one.
The new solution do not use oraclize.it, but a new type of graphene operation (account_balance_migrate_operation) will be added to the upcoming hardfork, user only need to signed a transaction including this operation for migration, for those who have not claim their balance to account yet, the "claim_balance_operation" will be keep for importing wallet in old format, but after the hard fork, some other operations such as transfer operations, asset management operations etc will be removed, so user could not transfer assets around after the hard fork. In the way, the system can not be mess up and users are encouraged to migrate to new Ethereum Dapp as soon as possible.
The hard fork is estimated to be happen at the end of Oct, and after that the Token Contract in new Dapp should already been fully tested and users can start to migrate then. A detailed migration guide will be provided, please stay tuned.
The new changes to the solution provides better experience, and besides, the new architect digram of the Dapp are under carefully design. There are some new feature for the new Token contract.
First, the new token contract is based on dapphub's ds-token contact, so it will consume less gas when transfering, at the same time, some good features form MiniMeToken, are borrowed to the new Contact, including TokenController supporting, ApproveAndCallFallBack Interface, record Transfer events when mint or burn etc. The TokenController supporting is very important because it could improve the extensibility to a new level, later the chip and game contracts could uprage it and support more functions.
Second, in the PLAY Token Contract, when transfering, the receiver could be an contract, and the contract could do anything he want right after it receive some token, the only thing this contract need to do is to inherit ReceiveAndCallFallBack interface. This is some great feature Dapp always want to have just like the Ethereum native ether payable fallback. This will enable the new Dapp token have something working natively just like the ether tokens. There is no other Dapp known are using this technology so far.
A lot of new researches and development will be done to improve the Dapp, now the Token Contract are testing on Kovan network, anyone interested could have preview in the following link:返回