SHARE
TWEET

Scam or legit? Uranus

c1s0r Jun 22nd, 2018 42 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. Chinese team. Very questionable project. Another "Amazon Cloud killer." Team has been in crypto for 6 years (right, we're sure they met up with Nakamoto for coffee daily). No token and no ICO. Questionable! (almost Scam)
  2.  
  3. # Overview
  4. ## Concept
  5. Chinese. Sketchy as fuck. Using computing power of everybody's devices to take on Amazon Cloud. No idea how. Use generic, broad, and very questionable statements without specifics about how they are different. Claim team experience that's almost longer than the crypto community (6 years in blockchain. Do they even have a token or ICO? The very definition of shitcoin.
  6.  
  7. ## Actual Product
  8. Cloud computing is too expensive, unsafe, and slow. They will somehow solve all of this. Apparently by creating a marketplace for people's devices' unused computing power.
  9.  
  10. # Site
  11. Visuals: Another space-themed template, and not the best execution either. It's in Korean and English.
  12. Uniqueness: The home screen isn't that great for navigating the universe. Everything else is standard: milestones, team, etc.
  13. Content: Plenty of complex technical text in pretty bad formatting. No registration forms of any kind. Just an email address .Site generally focuses on their mission, plans, sizable team, a little about the technical parameters of what they're trying to do, and, of course, about the huge market potential.
  14.  
  15. # Social Media
  16. Do have social media links (most are even clickable)
  17. - Reddit - brand new account, two weeks old. Absolutely clean of posts (or visitors, for that matter)
  18. - Telegram - almost 6000 members. No activity except for welcome messages from admin. But number of members growing rapidly
  19. - Twitter - fresh, just 128 followers and 4 tweets
  20. - Facebook - same, just starting out
  21. - instagram  - 6 people and... no activity
  22. - github - all quiet
  23.  
  24. # Team
  25. All of this project's activity revolves around James Jiang, who has experience working in the management of ZTE and in Beijing Cloud Times Technology Co.,Ltd. The latter is where he poached the entire cloud tech part of the team. Which is a strength of the project, since they've already had ready solutions in the virtualization area (the company held a pretty solid place in Asian markets). That whole part of the team associate themselves with the project in their social media accounts. The company's name morphed from China Cloud Power Technology Co. Ltd. to ubiCom Foundation to Uranus Foundation LTD.
  26.  
  27. The second half of the team consists of specialists in blockchain tech and in cryptography. Most notable is Zou Jun, who is active at blockchain conference, publishes articles, and is a rather well known media personality in Asia. Alarmingly, the blockchain part of the team joined the project fairly recently (back in March James Jiang was interviewed saying that they are not familiar with blockchain technology and need to urgently make up for that).
  28.  
  29. # Advisors
  30. Rather strong team of advisors, except none of them mention this project in their social media accounts. We are left to guess that possibly the Uranus team met Zishang Wang and Xinhao Lv at the TokenSky conference in Seoul. Zishang Wang is the founder of that conference, and Xinhao Lv participated in it. Also, ubiCom Foundation was a co-organizer of the conference.
  31.  
  32. # Whitepaper
  33. Has three versions: English, Korean, and Mandarin. It's a Technical White Paper.
  34. 60 (very long) pages of text, diagrams, and pictures.
  35. Lots of talk about their mission, problems, and how to solve them through their product.
  36.  
  37. ## Project summary
  38. Provide massive "ubiquitous computing" power to large projects, apparently by using spare computing power of participating devices. Creates a cloud to compete with Amazon Cloud, Microsoft Azure, etc.
  39.  
  40. ## Motivation and outlook
  41. Current cloud computing is too expensive, unsafe, and slow for distributed applications. Most of Uranus' claims are very dubious and generic (oh wow - you're so totally the first ones to think of distributed cloud computing via the blockchain.)
  42.  
  43. ## The Uranus solution
  44. This Chinese team claims not just 10 years of experience with cloud computing but also 6 years of "practical experience in the development and successful application of the consensus algorithm developed by public blockchain, proof of workload and development of smart contracts." Really now?
  45.  
  46. Their "solution" is to build several basic (in their own words!) extensions since blockchain by their own admission is pretty useless to their goal ("The blockchain cannot deliver services."). So they're building a "service delivery channel," "smart contract with rich content," "computing power containers," and more things that sound great to someone with a very high gullibility level. While at it, they are going to "transform the existing cloud native architecture" too.
  47.  
  48. **Token Economy**
  49. Found zero info on tokens or ICO. For a project where every owner of a participating device is supposed to benefit from the use of their computing resources, you'd think they would at least bother to invent a token, right?
  50.  
  51. ## Architecture of the Uranus System
  52. Uranus mainly comprises a service delivery system and a value delivery system in terms of architecture:
  53.  
  54. Service delivery layer:
  55.  
  56. * Ubiquitous cloud infrastructure, and standardized container metering
  57. * Use on demand, automatic settlement
  58. * Blockchain-based, decentralized computing resource pool
  59. * High throughput, high availability, and low cost to meet the needs of modern business
  60. * Container-packaged, dynamically managed cloud native applications
  61.  
  62. Value delivery layer (Uranus chain):
  63.  
  64. * Basic chain
  65. * uraTiller module
  66. * Enhanced consensus module
  67.  
  68. ## Uranus Chain Technology
  69. **System Architecture**
  70.  
  71. The Uranus system  builds a decentralized IaaS&PaaS lightweight operating platform and is comprised of:
  72.  
  73. - uraBlock
  74. - Uranus management engine
  75. - uraTiler
  76. - access gateway
  77.  
  78. Note that they say nothing specific about any of the above. Just some picture that we're supposed to figure out.
  79.  
  80. **Uranus Chain is comprised of:**
  81.  
  82. - The storage layer (storing info about the node's computing power)
  83. - The network layer (data transfer on the network)
  84. - The protocol layer (consensus formation)
  85. - The extension layer (dApp and smart contract launch)
  86.  
  87. **Uranus Chain Consensus Algorithm**
  88. They use a DPOS+BFT hybrid consensus algorithm. Plus, validators to increase consensus security.
  89.  
  90. Consensus protocol workflow:
  91. 1. Validator registration (the account needs to have a certain amount as a deposit; to get rid of validator status, can take out the deposit after a certain hold period, about one month).
  92. 2. A stakeholder may lend the deposit to the validator
  93. 3. Stakeholders elect validators by voting (thus increasing the weight of the validator)
  94. 4. Election for qualified validators (the top 48 validators ranked by weight participate in forming the consensus)
  95. 5. Package Transaction of qualified validators (when processing transactions, qualified validators can exclude other validators if they misbehave)
  96. 6. Confirmation of transaction information (if more than 2/3 validators vote yes - transaction is approved)
  97.  
  98. Additionally, the following three attributes are needed to measure the blockchain consensus algorithm:
  99.  
  100. 1. Agreement: All the honest nodes form a consistent decision
  101. 2. Validity: Transactions in the blockchain all come from honest nodes
  102. 3. Liveness: The consensus algorithm of the blockchain can always form a consistent decision without deadlock even if a lot of qualified validators are offline
  103.  
  104. **uraTiller module contains:**
  105. - Tiller virtual machine
  106. - Tiller native smart contracts
  107. - Interfaces of external data
  108. - Logically links on-chain data and off-chain data
  109.  
  110. Allows the creation of dApps on this platform.
  111.  
  112. **Uranus Computing Power Engine**
  113.  
  114. Capabilities:
  115.  
  116. - Automatically deploy and reproduce containers
  117. - Flexibly Scale-out
  118. - Manage containers across machines and organize better load balancing of containers
  119. - Dynamically upgrade application containers
  120. - Self-repairing capability
  121.  
  122. **Uranus Smart Contract**
  123.  
  124. Will use two smart contract types:
  125.  
  126. - explanatory Smart contracts similar to Ethereum (process user transaction information)
  127. - native Smart contracts in the uraTiller module (will utilize all the functions of the platform)
  128.  
  129. In the Uranus system, Oracle runs as a native Smart contract.
  130.  
  131. **PoC (Proof of Contribution) Mechanism**
  132.  
  133. Machines with a higher contribution value are more likely to be scheduled and allocated to users in priority, thus earning more tokens.
  134.  
  135. Total contribution value of containers = basic contribution value + service contribution value + chain contribution value
  136.  
  137. basic contribution value = total production capability of the node (CPU+RAM+bandwidth+storage)
  138.  
  139. service contribution value = comprehensive score through statistical analysis of the container's past transaction records and user's use feedback.
  140.  
  141. chain contribution value = for contributing to the voting in support of the system's stability
  142.  
  143. The platform will also automatically distribute computational load between nodes.
  144.  
  145. ## Computing Power Container Engine (CPCE)
  146.  
  147. The Uranus CPCE provides an application-oriented container cluster deployment and management system. The goal of Uranus CPCE is to eliminate the burden of scheduling of physical/virtual computing, network and storage infrastructure.
  148.  
  149. **Computing Power Container Engine Architecture**
  150.  
  151. The Uranus CPCE management engine draws on Borg's design concepts, such as Pod, Service, Labels, and single-Pod single IP.
  152.  
  153. **Uranus Resource Control Management**
  154.  
  155. Resource Controller manages all the resource-related underlying working.
  156.  
  157. **Multi-Region Scale Computing Power Container Management**
  158.  
  159. When the scale of the computing power containers is large, they manage computing power containers in different regions to lower the management, use, and service costs of each computing power pool.
  160.  
  161. In the original architecture, a Node manages a Worker node. Here, a Node manages multiple clusters. The Cluster Controller will maintain the health status of every cluster and monitor load status, while the Service Controller will find cross-cluster services.
  162.  
  163. **Computing Power Container Service Discovery and Deployment**
  164.  
  165. - Discovery:
  166.  
  167. The Uranus engine service is made up of a set of PODs, which are containerized applications. If there is a Worker cluster, which has an internal service called Mysql it's possible to access Uranus engine service through resolution of service names by DNS.
  168.  
  169. - Deployment:
  170.  
  171. The API gateway in the system will allocate an X-Traffic-Group identifier to each user request header. According to this identifier, HAProxy will route user requests to different deployment environments. In addition, the automatic health check tool will automatically check whether the HAProxy related to this service is healthy or not and check how many copies each Pod contains.
  172.  
  173. **Affinity and AntiAffinity in Computing Power Container Scheduling**
  174.  
  175. Due to the characteristics of the distributed peer-to-peer system, the Uranus engine enhances Pod scheduling, involving multiple-scheduler configuration changes, node Affinity/AntiAffinity characteristics.  Affinity and AntiAffinity are runtime scheduling policies, mainly including:
  176.  
  177. - NodeAffinity: It is used to specify which node a Pod can be deployed on or which nodes it cannot be deployed on, and solve the problems of Pod and host.
  178. - PodAffinity: It is used to specify with which pods the Pod can be deployed together under a same topological structure.
  179. - PodAntiAffinity: PodAntiAffinity: It is used to specify with which pods the Pod cannot be deployed together under a same topological structure and to solve the relationship between Pod and Pod together with PodAffinity.
  180.  
  181. **Workload Migration and Fault Recovery of Computing Power Containers**
  182.  
  183. uraContainer is used for realizing the pooling of distributed computing resources and the standardized measurement of virtual computing resources. The built-in self-healing mechanism for workload failures in the Uranus system will automatically help the user to select a new target computing power container in the shortest possible time.
  184.  
  185. **Computing Power Container uraContainer**
  186.  
  187. uraContainer is a container running on a hypervisor. It shows strong isolation, lightweight, and fast startup capability while supporting standard image formats.
  188.  
  189. **Worker and Agent Design**
  190.  
  191. Workers are the hosts really run by Pods, either physical or virtual. In order to manage Pods, each Worker node at least should run uraContainer, agent and proxy services. Pod is a set of closely related containers. They share PID, IPC, Network and UTS namespace. Pod is designed to support multiple containers to share network and file systems in a Pod.
  192.  
  193. ## Application Scenarios and Ecology System
  194.  
  195. **Application Scenarios**
  196.  
  197. Distributed implementation of general-purpose computing tasks:
  198.  
  199. - DNA computing
  200. - Computing of planetary orbits
  201. - Analysis of weather data
  202.  
  203. Projects based on edge computing:
  204.  
  205. - IoT node management and deployment
  206. - Voting platform
  207. - Advertising
  208. - Games
  209. - Data acquisition
  210.  
  211. Application Ecology (Block as a Service):
  212.  
  213. - One-click deployment
  214. - Container image supermarket and App store
  215.  
  216. **Business Application Examples**
  217.  
  218. * Network Data Acquisition
  219. * Voting Platform
  220. * Games
  221. * IoT Terminals
  222.  
  223. **Container Image and Application Ecology System**
  224.  
  225. * Container Image Ecology
  226. * Ecology of the Application Market
  227.  
  228. ## Development Roadmap
  229.  
  230. **Phase 1:** Community Version (V1) 2018/Q3 beta test and release a community version
  231.  
  232. **Phase 2-Phase 4:** Commercial Version (V2, V3, V4) 2018/Q4-2019/Q1 10000, 100,000 and 500,000 users/devices
  233.  
  234. **Phase 5:** Ecological Version (V5) 2019/Q2 1,000,000 users/devices
  235.  
  236. Then they have 10 pages about their "legendary" team, mostly just listing their achievements. Not a word about their token, ICO, or anything like that.
  237.  
  238. # Questions for the project
  239. Q: Who the fuck wrote this White Paper? Formatting is even worse than the content (which is a big accomplishment).
  240.  
  241. A:
  242.  
  243. Q: Key concept is nothing new. And there are a lot of ideas in their plans - no focus on a single area. Can they really pull off something so ambitious?
  244.  
  245. A:
  246.  
  247. Q: The "minimal balance on the validator" is very strange. What's the point there? To get more tokens into the network?
  248.  
  249. A:
  250.  
  251. Q: The token will get devalued a lot as the network grows. How will they solve this problem?
  252.  
  253. A:
  254.  
  255. Q: Will there be token buybacks?
  256.  
  257. A:
  258.  
  259. Q: Where are their tokenomics? Where is their ICO info?
  260.  
  261. A:
  262.  
  263. # Conclusion
  264. Experienced team started this project before the ICO boom and is now desperately trying to tie blockchain into it (without a clue about what to do with it). The White Paper is horribly written and formatted: double photos, stretched-out photos, low quality photos, tons of text that says nothing and outright explanations a la "want to know more - read a book." Linked GitHub is empty, though does link to a real one started in 2011 and finished in 2015.
  265. So many errors... looks absolutely unprofessional.
  266. But the team does seem to have real work experience with cloud computing. They do the conference circuit. And their social media accounts are gaining users.
  267.  
  268. # Verdict
  269.  
  270. Questionable!
  271.  
  272.  
  273. _**Disclaimer:** The above audit is not in any way financial advice or a solicitation to buy - it's merely our collective opinion that we are kind enough to share with you. Don't make us regret that._
  274.  
  275. **The report is prepared in partnership with** https://t.me/ico_reports
  276.  
  277. **Our links:**
  278.  
  279. - https://t.me/c1s0r
  280. - https://twitter.com/c1s0r
  281. - https://medium.com/@c1s0r
  282. - https://steemit.com/@c1s0r
  283. - https://golos.io/@c1s0r
  284. - https://pastebin.com/u/c1s0r
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand
 
Top