SUN Token Ecosystem Architecture Written by: Sun Token Technical Team Date: September 20, 2018 Version: 1.06

Transcription

1 SUN Token Ecosystem Architecture Written by: Sun Token Technical Team Date: September 20, 2018 Version: 1.06

2 Table of Contents Intro... 3 Non-technical stuff... 3 Our philosophy... 3 Problem... 3 Solution... 3 About the token... 5 Side chain... 5 Why a dedicated blockchain... 5 Delegated proof of stake... 6 Use cases / flows... 7 Architecture FAQ Frequently Asked Questions API calls User Identity Most important components and its API endpoints UserWitness QueryWitness Blockchain Document Proxy Award Confirmator Wrap up SUN Token Ecosystem Architecture Page 2

3 Intro Sun Token Ecosystem Architecture is a technical document describing a complete SUN Token architecture as a solution to a problem of having a platform that will ensure that users are in full control of their own data, that they will be compensated for their usage, and to provide full transparency for every single stage of the process. This documents is more of a technical nature, but is suited to also communicate our approach to SUN Token Ecosystem and represents our version of a White Paper. Non-technical stuff Before we dive into technical information, allow us to explain our solution in layman s terms. Our philosophy Ownership. Privacy. Compensation. Trust. This is the four pillars of Our philosophy. Trust The one thing that takes time to gain is - trust. Yet, we want you also to know you can trust us from the first sunrise of our project. Blockchain, decentralized public ledger is used in our system to record every single access to the data, and to be available for inspection by anybody at any time. Simple, yet effective Problem Of course, there is always a problem - we gain your trust, but how are we going to store large quantities of users data, such as video and images in blockchain? Presently, it can t be done, but every problem, for us, has a solution. Solution As there is not yet available reliable technology to store massive quantity of data in the blockchain, we decided to build a system as a hybrid between blockchain technology and traditional very fast ElasticSearch database with non-tampering log extensions. To make sure that there is no tampering with database on OS level, SELinux will be utilized with audit log turned on. Compensation of the data usage will be automatically regulated by smart contracts. SUN Token middleware, developed by us, will be the only point of contact with our system that will expose API for user management and data storage, to ensure maximum security. So here it is: Blockchain solution for data ownership and privacy. SUN Token Ecosystem Architecture Page 3

4 Best of both worlds - traditional and blockchain Final world before you begin, we built SUN Token Ecosystem to really change the world. But, we can only do it together with you so we hope you ll get in touch via our website, , Social Media and stay in touch. Let the new SUN shine. SUN Token Ecosystem Architecture Page 4

5 About the token This section describes into details the platform of our choice for the token, how it will be created, distributed, as well the reasons for programming our own blockchain. Side chain a. Token (SUN) will be created on the Stellar platform. b. How to c. We create several accounts on Stellar platform: i. ISSUER (issues SUN token) ii. PROJECT_DISTRIBUTOR (owns 40% of all tokens and sells them to fund the project development) iii. AWARD_DISTRIBUTOR (owns the whole award budget - 60% of all tokens. Once a user account has been created, a certain amount of tokens will be transferred to AWARDED_USERS account) iv. AWARDED_USERS (this is an aggregator of all awards issued to users for creating an account. Users can issue a request for token transfer to their own account on Stellar platform; this account is mainly used to store tokens belonging to users who don t have an account on Stellar platform) v. AD_DISTRIBUTOR (collects tokens which are used as a fee for search. It will distribute them in the 50/30/20 ratio to the user account, AWARD_DISTRIBUTOR and PROJECT_DISTRIBUTOR) vi. Special accounts: FOUNDERS, ADVISORS, LIQUIDITY_POOL 1. We will create a custom side chain based on graphene blockchain 2. It will be connected to ElasticSearch via SUN Token middleware components 3. ElasticSearch acts as a document store, indexing engine and search engine Why a dedicated blockchain SUN Token system is creating dedicated blockchain. The main reason for this are the expenses of existing chains. Moreover this platform is serving powerful feature set that are recorded within blockchain, therefore customization, improvements and optimizations on blockchain are very important, and customized blockchain development is chosen to avoid any limits to existing general purpose blockchains. As the basic platform bitshares/graphene source code is used. The platform base could be any of following: graphene, bitshares or steem. All those platforms are using the similar code base. SUN Token Ecosystem Architecture Page 5

6 Delegated proof of stake The concept of delegated proof of stake will allow every user in the system to vote and influence the blockchain network, additionally the cost approval work is smaller which will make this blockchain more efficient. In the first phases of the project the users will not use the voting system. There will be a master node (one or more), and several witness nodes. The users can set up their own witness to verify all data and operation on blockchain. As the system grows up and user base is extending, the user will be able to influence the network. With this approach decentralization is guaranteed and the cost of serving is low. Major concept will be used from bitshares/graphene implementation like transfers, custom currency (called asset) and other blockchain features. The system will be extended with operation that will ensure that advertisement and user data are traced within blockchain. It means that dedicated operation will be created for setting up an user and inserting an initial data set. This operation will move funds from special rewards account to user account in smart contract manner. This operation will require data hash that will be persisted and can be used as a proof for payments and user creating. New features and structures will support smart contract for executing the advertisement. The details will be covered in API specification. SUN Token Ecosystem Architecture Page 6

7 Use cases / flows Let s now take a look at the way we envisage the system will be used and what the expected user flow will be, one step at the time. 1. User registration a. User will choose a username, create a public / private key pair (also known as Brain Key on graphene) and register itself via Registrar middleware service b. Registrar will check username for uniqueness, it will check user s phone number and only then will create an account on the side chain c. Registrar will create an initial set of user data on Elasticsearch for this user (i.e. username with account id) 2. User inserts a first set of data (i.e. user completes the first questionnaire) a. User announces that it is going to insert its data set and supplies a SHA256 sum of its data set (data set is nothing more than a JSON object) b. If the user has already completed this operation, the side chain refuses it c. Side chain will create an object for this user and returns an object id. This object contains a boolean flag which tells us whether the user has completed the insertion of data d. DataWitness middleware service listens for notifications that these kind of objects have been created e. User sends its data set to the DataWitness middleware service. Data is encrypted using the key which is derived from the private part of the user s memo key and the public part of the DataWitness memo key. This guarantees the authenticity of the user. Data is then decrypted by the DataWitness and stored. f. DataWitness will decrypt the data set and check the value of object id together with the value of SHA256 sum. It accepts or refuses the data set. g. DataWitness will mark the user s object as finished if the data set has been accepted h. DataWitness will issue a reward to the user at this point. We track user s balance on the side chain i. User initiated operations: i. Initiation of insertion of user s data set j. DataWitness initiated operations: i. Insert completed ii. Issue reward tokens k. Query for DataWitness i. Get a list of all pending insertions 3. User edits / deletes its data set a. Similar to the b) step. DataWitness will not issue new rewards b. User initiated operations: i. Initiation of editing of user s data set ii. Cancel edit c. DataWitness initiated operations: i. Update completed d. Query for DataWitness i. Get a list of pending edits / deletes 4. Search SUN Token Ecosystem Architecture Page 7

8 a. Marketing agency wants to reach our users (Searcher) b. Init AdQuery that will return how many matches are found c. Side chain saves the query, generates a memo and a search object d. Searcher will transfer a certain amount of SUN tokens to Collector e. account using the generated memo f. Search middleware service listens on Stellar Network for transfer to Collector account which has a given memo set g. When such transfer has been detected a query result is prepared h. Details TBD: at this point we send an to the user who appears in the search result set i. It is possible that Search resides on our side chain. In that case, search fee can be paid directly as an operation fee (in bitshares terminology) j. Search middleware sends / issues reward tokens to users k. Search middleware marks the search object previously created as complete l. Operations initiated by Searcher i. Search ii. Search with fee iii. Mark search as completed iv. Issue reward tokens m. xii. Query i. Get a list of all created but not completed searches 5. User wants to set SUN token a. We transfer SUN tokens from Collector account the give user account, using the user supplied memo b. We deduct the account balance on the side chain c. (details are needed here) 6. Internal wallet on side chain a. Send tokens between users b. Trade tokens on internal exchange c. Future use: Additional operations signed by users for Search middleware SUN Token Ecosystem Architecture Page 8

9 SUN Token Ecosystem Architecture Page 9

10 Architecture Let us analayze in detail explain how the architecture was designed and built. There are five major components: subsystems, blockchain, data storage, user interaction and Utils (toolset). Here is the breakdown of each. 1. Subsystems a. Stellar Connector - This subsystem controls the token flow between stellar account that are controlled by following services: i. Award Confirmator - moves tokens from stellar AWARDS_DISTRIBUTOR account to AWARDED_USERS account. Each transfer contains trace to SUN side chain that keeps all details. Those two chains are connected with memo field that is set during every transaction. ii. Award Translator - moves tokens from stellar awarded account to specific user. This action is initiated by user and user should submit stellar address. Such action must be secure, breaching this action the users funds could be redirected to wrong account. Therefore the strong recommendation is to verify user s address on confirmation. Another option is that users signs this address with it s private key and encrypt with public key of this service. iii. Ad Distributor - dispatch tokens for an ads to other accounts in ratio 50/30/20. This service will poll the stellar AD_DISTRIBUTOR account to check if the AD was paid. As soon as the tokens arrives the service will forward the funds to users, project and award accounts. 2. Blockchain - This blockchain is customized to fit specific needs for ad platform. It ensure data integrity and connection with other components a. Signing Node - These nodes sign all blocks and ensure all benefits that blockchain and decentralisation is bringing. (Note: such nodes are called master in graphene blockchains) b. Checking Node - These nodes verify all blocks and ensure transparency. It could be run by anyone. (Note: such nodes are called ledger in graphene blockchain ) c. UserDataWitness - This microservice connect blockchain data with user data and ensures immutability. It is responsible to verify user data hash and transfer token to user account on side chain. d. AdDataWitness - This microservice connect blockchain data with querying data and ensures immutability. When the search query is executed and advertiser confirms processing the ad. The payment is verified by AD_DISTRIBUTOR and tokens are funded than this query will be hashed and appropriate operation on side chain is executed. 3. Data Storage - This subsystem ensures all data is stored and can be queried. SUN Token Ecosystem Architecture Page 10

11 a. Elasticsearch - It s document store will offer flexible data structure that represents different user data structures and will be ready for changes in future use b. NonTempering Helper - These tools and utilities ensure that access logs are stored back in DataStore and its hash could be stored in blockchain 4. User Interaction - This subsystem will serve all data to users in user friendly manner a. Static Web Server - This server (or server pharm, or cdn) will server static content for user applications. This component will also serve as proxy for dynamic requests in order to prevent direct access to internal system components b. Platform Application - This web application will serve all interaction with user data. In later phases it will grow and integrate social network functionalities. c. Block Explorer - This application will show all details about side chain blocks and relation with stellar blockchain. Other token info will be stored here. d. AD Helper - This application is everyday tool used by advertisers. It offers advanced queries and other mechanism that will help advertiser to find the best users to show them appropriate AD. 5. Utils - This is a toolset that is required to maintain system and enhance its development and troubleshooting. a. Service Monitors - Check and alarms status of all services in the system b. Blockchain Tools - Different command line tools and scripts SUN Token Ecosystem Architecture Page 11

12 SUN Token Ecosystem Architecture Page 12

13 FAQ Frequently Asked Questions In order for us to further speed up the introduction of SUN Token Ecosystem, we ve also prepared a FAQ section to try and help you find answers to the most common questions we ve encountered so far. If you have additional questions, please get in touch with us, using contact or our Social Media channels, out team will be ready to answer them. 1. What blockchain to use to record all access to data? i. The graphene/bitshares blockchain is used as a base to develop a new blockchain that will ensure all data are traced. The whole access logs and queries will not be saved within blockchain, but its hash will be stored. With this approach it is guaranteed that data is not modified and the access data is stored on Data Store subsystem. 2. What data will be written in blockchain and what data will be written in database? i. Blockchain will keeps the track of operations that have happened and hash of the data that are related to those operation. The queries, logs, user questionnaires are stored on Data Store, but its hashes are stored within blockchain. 3. How to combine blockchain that records access to data with our own token for payments and smart contracts? i. The blockchain will have a special operation that will act as smart contract. Therefore such operation will require appropriate tokens to be funded in order to serve Ad. Also these smart contracts will use a hash that is based on non-blockchain based data. With this approach those two systems will have a data that are strongly dependent on each other and it will guarantee immutability and all other benefits of blockchain architecture. On the other side the whole flexibility that NoSql database offers will be used in order to deliver the best userdata for advertising. 4. How/If to delete data from blockchain and how to keep records about database data deletion? i. Any data change will be executed on the blockchain, but the data hash is only stored in blockchain. Therefore the deletion could be considered as the special case of updating data. The data in Data Store subsystem will be deleted, but the has of deletion will be stored in blockchain. 5. What network to use for our own token, Stellar, Ether or something else? i. Stellar. It will be used to create the token and holds the special accounts. Each transaction will have a memo field that reference to specific action and user in the side chain. 6. Based on token network, how to implement smart contracts to ensure payments to users? i. There will be service that connect stellar and side chain. Those services will ensure that information from side chain will be stored in SUN Token Ecosystem Architecture Page 13

14 transaction and therefore sidechain functionalities will have the trace on Stellar network 7. Wallet i. How to implement wallet? i. Users will be able to use stellar wallet to spend token on stellar network. This will be possible when the balances are transferred from side chain to the Stellar chain. ii. Where to keep wallet, with us or users will have their own wallet? i. User will keep it s own keys at their local computer or any other safe place. 8. Database i. What database to use (SQL vs nonsql)? i. NoSql, ElasticSearch. This database will offer flexible structures, therefore it will be able to serve different needs that could be changed in the future. Also this database is very scalable. 9. API i. API needs to be defined, how to do it? i. The most critical API calls can be defined from existing data flows. 10. Deployment i. Architecturally we want software to be microservices, deployed using Docker containers on Kubernetes. Is it possible solution? i. I don t see any obstacles to have automated deployment. The best advantage would be in the service that will scale and it seems to be the services within Data Storage subsystem. 11. Security i. How to ensure security of our own system? i. Restrict access and setup firewall on all non-public services. ii. How to ensure overall security of blockchain? i. Signer(master) nodes don t have to be public, only ledger. SUN Token Ecosystem Architecture Page 14

15 API calls This section outlines basic public API information and calls which will allow user management and data storage. User Identity There are several parameters that should be unique per user. Those parameters are: i. Blockchain_id ii. Username iii. iv. External Identifier (like facebook, gmail or other platform that could be used for login) Those identifiers are relevant in different parts of the system. For instance blockchain id is crucial for blockchain system, but could be insignificant data for Social Network. On the other side username/ is useless data for blockchain component. However having different identifier in different part of the system will produce a lot of potential problems with id mapping and will make the whole system more complicated. In order to avoid this the blockchain_id is used as user identifier in all system parts. This id could be easily converted in any other identifier. Most important components and its API endpoints UserWitness 1. errorcode CheckIdentity( , username, blockchain_id) a. - Invoked by WebPlatformApplication This API call will verify if the user exist on DocumentStore and check the user on Blockchain. 2. blockchain_id CreateUser( , username) a. - Invoked by WebPlatformApplication This API call will create user on DocumentStore 3. errorcode InitUserData(blockchain_id, encrypted_user_data, data_hash, signed_operation) 4. - Invoked by WebPlatformApplication This action will validate if the user is completed on blockchain and on DocumentProxy. If the user is valid It will forward signed operation for assigning user hash to user. This operation is forwarded to the blockchain. Also the service will subscribe for notification when this action is completed. As soon as the confirmation notification is received the service will submit data to DocumentProxy. When this action is completed the notification is sent to PlatformApp or confirmation is sent. SUN Token Ecosystem Architecture Page 15

16 QueryWitness 1. queryresult QueryAD (querycriteria) - Invoked by WebPlatformApplication This action is the initiated by advertiser. Web platform will generated dynamic criteria set and send it as json object. Query Witness will execute this query and return the count of affected users and costs per user. If the query results fits clients needs it will confirm query execution. 2. queryresult ExecuteAD (querycriteria, query hash, user_count, signature) 3. - Invoked by WebPlatformApplication This action is the initiated by advertiser when the user confirms an advertisement. QueryWitness will execute the ad and initiate the Ad payment in blockchain (call PayTheAdvetisement). Ad execution could be sending an or leaving special messages in social network mailboxes. Blockchain 1. errorcode CreateUser(username, pub_key) a. - Invoked by UserWitnes 2. errorcode IsUserRegistrationCompleted(id) a. - Invoked by UserWitness 3. referencecode InitUserData(id, hash, user_witness_signature) a. - Invoked by UserWitness This will assign user hash to user and move balance from award account to user account SubscribeToResult (referencecode) The operations are not confirmed until the block is verified the blockchain, therefore the confirmation will be delivered through subscription.reference code is used as a tag in order to identify the pending operation 5. referencecode PayTheAdvertisement( user_list, ad_hash, signature) The operation are not confirmed until the block is verified the blockchain, therefore the confirmation will be delivered through subscription. 6. int GetUserBalance( blockchain_id) 7. TransferBalance (from, to, signature) [ other common cryptocurrency operations] Document Proxy 1. errorcode CheckUser (id, username, ) 2. errorcode CreateUser (blockchain_id, username, , phone, ) 3. bool IsUserCompleted (id) SUN Token Ecosystem Architecture Page 16

17 Award Confirmator 1. errorcode ConfirmAward(amount, bck_id, hash, action ) This will transfer sun tokens from award account to awarded account with user bclockchainid_action in memo text. Data hash and other details are stored in internal log. SUN Token Ecosystem Architecture Page 17

18 Wrap up We don t have the end, but a wrap up, since this is just the beginning. Stay connected and in touch, so we can build and grow the SUN Token Ecosystem together through our website and social media channels. contact@suntoken.io Official Medium Twitter YouTube Also, check out our official SUN Token Ecosystem Architecture Page 18