0% found this document useful (0 votes)
6 views3 pages

White Paper

Uploaded by

chad.iksde
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as ODT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
6 views3 pages

White Paper

Uploaded by

chad.iksde
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as ODT, PDF, TXT or read online on Scribd
You are on page 1/ 3

Unipy is a cryptocurrency network.

It’s main philosophy is that everything is


not constant. Everything that should be not constant, is not constant. But everything
that should be strictly unchangeable, should be that way and no one can say
otherwise. It’s very inspired by Ethereum network, which is one on the most popular
cryptocurrency systems on the world. UniPy uses some of the previous discoveries of
Bitcoin, Ethereum etc. and introduces many more original ideas in the same time. As
UniPy is not a currency, rather a network, everyone has a right to create currencies,
items etc.
Accessing UniPy system is different, than accessing other systems. You can
enter those by many different pathways, but the most common one is by hardcoded IP
addresses. Clients connect with those IPs to connect to the network. Of course this is
only one of the possible pathways, but UniPy takes different approach. The users on
the UniPy system willingly host a website on their PCs. Since the website address
“masks” server IP, it works as a one-time invite link. When client tries to connect, it
just creates a TCP connection with the website (or the user that hosts the website). If
user agrees, that it’s a valid connection, it allows user in.
The main point of cryptocurrencies is that, you can send money without any
middlemen. The verification of the transaction is made by users (in a process called
mining). However, everything that has a margin of error, on UniPy is verified by
protocols. Protocol can be defined (in this particular context) as a set of instructions,
that needs to be done to successfully complete an action. Most of the protocols are
documented. Meaning that every successful (or not) action will have it’s own page in
a history book. When something fails within the completion of the protocol, it will
not be valid and an exception will be thrown to handle the situation.
There’s also a problem with memory. If users start to create more and more
transactions, more and more bytes will be reserved for handling those transactions,
more will be for saving them to the history book. How do we handle this? Well, we’re
going to do this by introducing new players onto the table. Data handlers! They’re
special type of users, which basically have one extra privilege. Storing data. Those
users are aligned in a big row (which you can refer to it as a chain). And to each data
handler, there are plenty of users connected (image below).
Every data handler has a capacity of 500 MB. They can store that much data in the
same time. However if that threshold is passed, then data handler is oversharded (or
just stores too much data). However it’s fine, until data handler stores ~650 MB of
data. Now, data handler enters panic mode, and tries to garbage collect as much data,
as it can. When data handler stores 1GB of data its temporary shut down. It will
remove any sort of data to free the memory. Although this situation is possible, we try
to minimize chances of that happening with something called “sharding”. Sharding is
a process of adding another data handlers to the chain, to store more data. If the
oversharded user sees, that he stores too much information, it will pass this data to
other data handlers, that have more space available.
Mining, in a traditional meaning of this word, is not present in the network. It’s
replaced by it’s more eco-friendly, less hardware dependent alternative. Miners are
also a special type of users, that specialize in solving problems in the process of
mining, and also can be customized by users using “nodes”. There are currently 10
types of nodes:
• Heap node
• Module node
• Double node
• Decision tree node
• Stake node
• Learning node
• Worker node
• Calculus node
• Lazy load node
• Custom node
Each miner can have infinite amount of nodes, but every node requires loading and
processing, which takes time. Miners solve tasks, divided on 3 different difficulty
levels. Easy, medium and hard. Easier tasks require very low computational power
but the payment for solving those is also very low. Harder tasks, on the other hand,
require much more computational power but you receive much more money. Miners
do their stuff on sessions. Each session has its own hashrate, which is a random
number between 0.0001 $ and 0.001$. There are two types of sessions: Challenges
and Multicomputing.
In challenges, there are two types of miners. Teachers and students. Teachers
have a set of 100000 questions each. Students need to solve those questions. They
pick one randomly, and tries to solve it. The equation for receiving cryptocurrency for
successful completion of the task is:
clamp(easy_task = 1, task_solved = ( by default is 2, medium task), hard_task = 3) *
(hashrate – (time * hashrate)/20 + (computational effort% * hashrate)
Teachers on the other hand have its own “hashrate” (which is hashrate +
random number between 0.0001$ and 0.001$ for each teacher). Whoever task set is
finished first, receives 50% of current hashrate.
Multicomputing is different than challenges and is pretty similar to mining
found in other cryptocurrencies. There, miners try to solve a very difficult problem
and by every line of this problem solved, miner gets a contribution percentage. When
the session is finished, every miner receives a cut in a hashrate, based on contribution
percentage.
We talked enough about sessions, now it’s time to talk about tasks. As we
mentioned earlier, tasks are divided by difficulty. Easy, medium and hard. However,
what are those tasks? Well, sometimes, when the protocol outcome is not really sure,
it’s moved to the task list and for now on, it will require validation by miners.
Validation is a mix of proof-of-work system, but flavored with some less energy
expensive solutions to make that algorithm more eco-friendly. But most of the time,
tasks are made by the community. To make a task, user must spend around 2-5$ per
line of code and 10$ for every library it includes. Now the user also have to clarify,
how much money that task provide. After that, task is added to the list and it’s ready
to be solved. You can make tasks in JavaScript and they can vary from simple shader
compilation, to whole machine learning model. Possibilities are endless.
Now it’s time to talk more about protocols.

You might also like