Jura, a company specializing in creating highly advanced, secure distributed ledger technology has announced that it acquired DATO AI Technology, a company that specializes in IoT technology and high-end, luxury smart devices. This acquisition will serve both companies by merging smart home goods products such as cameras, security systems, and other SMART home devices with advanced security technology designed to protect the private information of customers.
As their first act as a newly merged company Jura and Dato AI are giving aid to emergency centers in the form of donating protective equipment to hospitals, including Elmhurst Hospital. As many hospitals are dwindling in supplies during the pandemic, the two companies have pledged to aid them by donating emergency supplies in order to reduce the risk of transmission of the virus both to and from hospital workers. DATO AI’s main office is in the middle of the crisis center, in the heart of wall street, and they are acutely aware of the hardships that this crisis has wrought on the struggling healthcare systems.
A JURA representative commented, “The healthcare systems are struggling to meet the needs of the hospital workers. Protective masks are needed to reduce the risk of infection, and they are a necessity to the brave hospital workers. They need proper protective equipment in order to do their job and save lives. It is up to everyone who is capable of helping to do their best to combat this virus as a community. Whether you’re donating, or just staying at home in self isolation, we are all still fighting together.”
JURA ACQUIRES DATO AI TECHNOLOGY
Secure IoT-based Smart Home Automation Powered by JURA Blockchain Technology
Jura, a company specializing in creating highly advanced, innovative distributed ledger technology has announced that it acquired DATO AI Technology, a company that specializes in IoT technology and high-end, luxury smart devices. This acquisition will serve both companies by merging smart products such as cameras, locks, sensors and other devices with advanced security technology designed to protect the private information of customers.
This acquisition provides Jura with SMART products that are already proven to be successful, and allows them to continue implementing real world use cases, resulting in products that will be unmatched when it comes to convenience and safety, secured from threats (hackers, crackers, cyber-spies and data theft specialists).
The CEO of Jura stated about the transaction, “This acquisition represents an important strategic opportunity for both companies, as it allows us to perfectly merge our strengths, and provide the market with luxury products that are safe, secure, and trustworthy. DATO is company that already has a foothold in the home security and smart hardware market, and this acquisition will allow us to take their products to the next level.”
Through its use of cryptography algorithm and collective intelligence in peer-to-peer network, Jura aims to increase the security of IoT products while solving many issues that have resulted due to data centralization. You’ll have smarter, faster, and more secure products that can function on their own without the need to send your data to unsecure networks. Furthermore, the smart contract function and artificial intelligence component can further automate the system, rendering extra ease and comfort.
A spokesperson from DATO AI added, “The added security of Jura’s technology will provide value and safety to all of our future products, and soon become the industry standard when it comes to protecting both private data, and homes”.
How do IoT and Blockchain coexist?
Kevin Ashton is an innovator and consumer sensor expert who coined the phrase “the Internet of Things” (IoT) in 1999. In 2015, Kevin’s words were cited by Smithsonian magazine again:
“In the twentieth century, computers were brains without senses — they only knew what we told them. That was a huge limitation: there is many billion times more information in the world than people could possibly type in through a keyboard or scan with a barcode.”
The Internet of Things, popularly known by its acronym IoT is essentially comprised of several devices everywhere in the world that helps send our sensor data to different systems, the systems in return observe, report the data and subsequently respond to it.
What Kevin did not foresee was the invention of the blockchain — a technology that allows you to store data in a transparent and unchangeable manner — that provided the Internet of things with solutions to many (if not most) security problems that prevented it from realizing its integrity to its present potential.
Blockchain features such as “principal (node) equivalence”, “openness and transparency”, “multi-party consensus”, “information is hard to tamper with” and “programmable” may have a profound impact on the technology system, infrastructure and operation model of the Internet of things.
It is generally believed that the blockchain technology and can solve the traditional three problems in the development of IoT:
(1) Solve the problem of operating costs higher. Blockchain + IoT can use peer-to-peer (P2P) transmission to solve the problem of network bandwidth limitation. The computing resources, storage resources and data resources of hundreds of millions of idle nodes of IoT are utilized in a distributed way. So as to greatly reduce the high operation and maintenance costs under the “centralized” architecture of the traditional IoT and promote the flow and sharing of information.
(2) Solve the problem of safety in IoT node. Blockchain + IoT can adopt timestamp-based storage structure and distributed storage mechanism to construct verifiable and traceable electronic storage certificate, to protect the integrity and tamperability of data, and solve the security problem of IoT under different trust domains nodes. Such as:
Security issues faced by IoT in the “Financial Economy” field include information falsification, bank credit, fraudulent goods misappropriation and remote supervision. The features of blockchain, such as trustless and data encryption, can help improve the above security issues and realize the integration of freight finance.
Security issues faced by IoT in the field of “Intermediaries” include false information, user privacy security, etc. The use of smart contracts in the block chain can achieve mutual trust, ensure the security of user information, and weaken the intermediary’s asymmetric control over information.
Security issues faced by IoT in the field of “Data storage” include storage centralization, data security, etc. The “decentralization” of blockchain can be used to improve the “centralization” of big data storage, and the blockchain data encryption technology can be used to ensure the security of files.
Security issues faced by IoT in “Public services” include food safety, medical safety, traffic congestion, etc. The timing data of the blockchain can be used to mark the origin and date of food (with the “natural” characteristic of “inalterable “). Encryption of medical data to protect users’ privacy, and blockchain technology is used to realize real-time sharing of traffic information.
(3) Solve the problem of cooperation between IoT devices. Contracts using blockchain intelligence technology to the traditional Internet of things intelligent device can regulate the individual self-maintenance. To make the individual in the case of without artificial participation, according to the rules or the rules of the implanted contract beforehand that exchange information with other individuals or verify the identity, namely can realize the intelligent collaboration between Internet of things devices.
However, as the blockchain technology has not been completely finalized so far, many application scenarios of blockchain + IoT are still in the proof-of-concept stage, and the real typical applications are rare.
Blockchain is still comparable to the Internet of a few decades ago. The Internet as we know it today looks very different, and so does the expectation of blockchain. Essentially, blockchain can add a completely new dimension to the Internet by introducing new standards for data transparency and peer-to-peer communication.
FUSUS Data Structure Demo!
In this article, we’ll explain how our FUSUS Data Structure works. The links for you to actually try it out yourself will be at the end of this article. So let’s dive right in!
FUSUS Data Structure
FUSUS is Jura’s novel data structure that is a multiple inheritance of blockchain, block lattice, and directed acyclic graph (DAG) technology. The FUSUS is a flexible, practical, and scalable data structure that provides us with the ability to achieve scalability, fast transactions, lightweight, and instant confirmation all at once.
The FUSUS is essentially a DAG-lattice. This essentially means that the transaction histories of accounts form the lattice, and the history of each account is constructed by the DAG. In simple words, when the traffic volume is low, the DAG is effectively reduced to a blockchain structure, but when the traffic volume is high, the RTs form a DAG, and every ST plays the role of a new genesis block.
Let’s see it in action. We’ll start with a balance of 1000 JREX in our genesis block.
Genesis Block with a balance of 1000 JREX
When there is a receiving transaction, the structure will take a form of a DAG.
But when we send JREX over to someone, the sending transaction will act as a new genesis block and will form a blockchain.
Sending Transactions are Genesis Blocks
As you can see, the new structure is a Blockchain-like structure comprised of all the sending transactions. Sending transactions are usually low-volume so blockchain structure is perfect. But you might receive multiple transactions therefore the chances for a higher traffic are high hence a DAG-lattice structure is perfect for scalability. This graph can get very complicated as we scale.
As we scale, the structure becomes complex.
Here, try it yourself by following this link:
Jura Second Layer Solution — A Brief Summary
Jura Second Layer Solution
Introduction
Layer 2 blockchain technology is often referred to as an “off-chain” solution. Its main purpose is to scale blockchain transaction capacity while retaining the decentralization benefits of a distributed protocol.
Solving the scalability problem will significantly help with blockchain mainstream adoption.
To build a good blockchain ecosystem, we need a few things in the architecture to balance the needs of security, decentralization, and scalability. Basically, rather than changing the base protocol, we add smart contracts on the main blockchain protocol that interact with activities off-chain.
Layer 2 tech will help us scale the blockchain platforms in whatever industry they’re implemented in and compete with the likes of established, centralized systems like Visa or MasterCard.
Here we provide Jura’s second layer solution. In the Jura network, each account information is stored and processed in FUSUS data. The smart contract in Jura is an internal contract account which basically is also FUSUS data. Jura’s second layer solution caters to both off-chain state channel for both Jura and other existing decentralized technologies which desire to utilize the scalability of Jura to be ultrafast and near feeless while remaining decentralized and secure.
JURA Second Layer Protocol
The aim of Jura’s second layer is to incentivize and enforce smart contracts. The approach is simple:
Construct a smart contract on the main chain
The second layer’s history and its computation is committed to efficiently prove that something is in the set without storing it (saves storage)
If a conflict happens among the second layer participants, the Merkle proofs from different participants are broadcasted and committed to the main chain which after consensus comes to a decision (e.g. penalize the false participant). Currently, there are a lot of decentralized projects that can scale by using Jura’s second layer protocol.
JURA Smart Contract Specification
JURA smart contract, in the form of Fusus data, is initialized by external account and controlled by the code in that account. The receiving transactions and message calls form the DAG in the Fusus data structure which is the same process for checking balance by sending a balance-amount transaction to oneself. The sending transactions form a sending chain. These sending transactions then apply transactions and message calls to get you to a new state. Every sending transaction is also responsible for calculating the latest state.
Since the second layer solution doesn’t commit state transition for every sending transaction for the global ledger, it does make sense to specify a type of smart contract that also involves multiple participants and commits state transition during finality or conflict.
This type of smart contract can be inherited from other decentralized projects by transferring the contract deposit, initial state and rules for computation. We call this type of smart contract the second layer smart contract!
State Channel in JURA
To create a multi-participant off-chain state, we need to initialize a second layer smart contract with a certain amount of deposit. This will allow participants to interact within the smart contract: exchanging tokens, playing chess, insurance etc.
Participants will interact with each other by sending transactions or message calls to the smart contract which Fusus will record as a receiving transaction. If these transactions are independent and not order-sensitive, these transactions will form a DAG which has the potential to increase the throughput. But every time Fusus gets dependent transactions, it will generate a sending for the purpose of state transition and the order is naturally sorted out.
The receiving transactions between two consecutive sending transactions in a second layer smart contract are defined as an interaction round. It is followed by a state transaction which must be signed by all stakeholding participants.
For example, if the contract keeps the balance between Bob, Alice and David, if one state transition is Bob sending money to Alice, then the balanced output of Bob and Alice changed, but not David. This round of state transition must be signed by Alice and Bob, but not David. This is necessary to keep the proof minimal. In Fusus, the sending transactions hold the state transition whereas the second layer smart contract process off-chain state transition. Participants must agree in order to proceed.
This is what the process looks like:
The smart contract specifics a data in storage as “output at stake”
Next state contains the header of the previously signed “output at stake” to achieve security and finality between participants.
The smart contract keeps a “summary state”. If the state channel is a payment channel, the “summary state” records all deposits in this channel.
Note: As “output at stake” is an explicit result after computation, it solves the problem if participants have different environments and output is enforced to come to consensus off-chain to proceed. The ”summary state” must match the total state of all participants’ individual state in this channel. In a payment channel, it means that each participants’ balance inside this channel must add up to the total deposit in this channel.
The case for a participant to exit the channel is not as trivial as new participants. Exiting may happen when participants think validators withhold the transaction or simply want to quit this channel. Exiting requires on chain state update. Normally, if one wants to quit a channel, one must broadcast a state that in the channel after which its ”output at stake” no longer change. We do not expect one to commit the most current state as state transition happens very fast inside the channel. Once it provides the merkelized proof of that state, it needs to wait for some time for other participants’ attesting. If any other participant in that channel provides a newer signed state with some change to that participant state, which proves that this participant is dishonest, and fine will be paid.
In the next section, we will discuss the types of application which need to process a large number of transactions every second.
Stay tuned.
Have a conversation on the merits of blockchain, not on the price of bitcoin!
After the burst of the bitcoin bubble back in 2018, companies and the stakeholders have become more critical of the technology. The adoption has become difficult but if a company successfully delivers value, the adoption is inevitable.
However, I can sit down with someone and talk all day about blockchain, supply chains, and the increased awareness we’re seeing compared to when we first got into the market — it won’t matter.
The last question will always be: “So, what do you think the price of bitcoin is going to be next week?”
Yes, it’s great that cryptocurrency and financial applications are finally getting mainstream coverage. But that tends to come at the expense of other applications for blockchain.
This begs the question: How can we reach our customers on the value blockchain delivers not on what the price of bitcoin will be next week?
Here at Jura, we have discovered three ways in which we can have a conversation around this topic on the merits and potential value of blockchain.
Education First Approach
Traditional marketing strategies don’t work as well for an emerging technology like blockchain.
It’s not as simple as buying advertising space or driving traffic to a website.
You can’t properly market a product to someone who doesn’t understand it.
Educating the market about blockchain is essential if we want to get people interested and on the path to becoming customers.
At Jura, educational content is at the heart of our marketing strategy. We’re most successful at educating when engaging with people on social media or at a speaking event, on a panel, or face-to-face with a customer. It gives us an opportunity to share what’s happening in the industry. And we want to share not only what we’re doing but what our partners and other companies are doing.
Build Hypothetical Use Cases & Show Business Value
At the moment, we can’t just list our blockchain products and solutions and hear people say, “Ah, okay. I understand this. I know what you’re selling.”
The best practice right now is to provide real-world examples and thought leadership to ground people in the possibilities of blockchain.
Before delving into implementation, look through the catalogue of our case studies and tech explanations. Gathering and familiarizing yourself with the basics of technology is crucial before you start talking about implementing it. We at, Jura, make sure our potential customers understand the value from a business point of view not just the technology point of view. But before that, we make sure that our customers successfully understand the underlying basis of this new technology.
The influence this makes on the mentality of our potential clients is significant, and it helps us explain the practical applications of blockchain in a more productive manner.
Focus On Unbiased Sharing Of Knowledge
The biggest growth strategy for blockchain-based companies is the formation of ecosystems or networks around a particular solution.
This is where influencers are incredibly effective. They have the ability to bring a group of people together around that specific use case.
And it’s not just individuals.
Blockchain also has the ability to bring together groups of competitors to build new infrastructure for the future.
A good example is what we do at Jura with the blockchain’s developers community. Every month in our meetups, we bring together aspiring blockchain developers and educate them about the technology. We do not do that in isolation but we make sure the business aspect and use cases are covered. We have group discussions and ideas sessions. The main goal is to think about the customer when developing a blockchain solution. This is what will make blockchain enter the tech stack of the mainstream market.
The best way to commercialize the different uses of blockchain is by building an ecosystem or community with a specific solution in mind. It’s essentially a collaborate-to-compete model.
The Way Forward
Sharing is the true spirit of decentralization and the blockchain community.
We’re trying to create an open form mentality, not only sharing use cases, but also knowledge and experience. We need to be sharing data, not competing in a way that creates data monopolies (similar to what we saw in the early days of the internet).
That attitude of sharing and collaboration isn’t just important for building incredible code or blockchain-based ecosystems — but also for building the right industry reputation and a solid marketing strategy.
It’s going to take time, but building a community with its own set of checks and balances will go a long way towards promoting blockchain and educating consumers.
Thank you again for supporting us! We always appreciates your support and company.
‘Till next time.
The Crisis: How Jura Prevents Malicious Attacks?
Jura, like all other decentralized cryptocurrencies, is prone to attacks by malicious parties for financial gain. From the historical evidence, we know a few possible attack scenarios that Jura might have to face. In this article, we present the consequences of these attacks and how Jura prevents them.
1. Monopoly Problem
This problem is common due to the nature of decentralized networks. In this attack, a single entity (monopolist) takes control of the majority of staking resources. The monopolist uses these resources to impose limitations on the network that can hamper its functioning. Potentially, the monopolist could choose to do this in malicious ways, such as double spending or denying services. As a result of such malicious strategies and the monopolist’s control over the network, purchasing power drops and confidence in the system shatters. Even if the monopolist acts in good faith, it is a sign of centralization that is unacceptable.
To counter this, our Proof of Utility (PoU) consensus mechanism makes acquiring high stakes expensive and takes away the economic benefit from a maliciously acting node. In addition to the traditional methods, our PoU system also hides the way of obtaining 50% of the stake in the network.
In our system, the voting power of every single entity is a result of many factors in a game-theoretic approach in the population, and the non-linear transformation via CDF from the stake size to the marginal utility eliminates the possibility of dominating in any sort. We are aware that an outlier can change the mean by a large amount, but cannot change the median value no matter how far it is.
2. Block gap synchronization
An improperly broadcasted transaction can cause the network to ignore subsequent blocks. There are two ways a node can react after observing a block without any reference to the previous block:
1. Ignore the block as it might be a malicious garbage block
2. Request a resync with another node
In the case of a resync, a TCP connection must be formed with the node to facilitate the increased amount of traffic. However, if the block was malicious, then the increased traffic and resync were completely unnecessary. This is a Network Amplification Attack and results in denial of service.
To avoid unnecessary resyncing, nodes will wait for votes to reach a certain threshold in favor of the block before initiating any connection with the bootstrap node. Otherwise, the block will be considered junk data.
3. Double Spending
Double spending can happen in two main ways:
1. Users send the same balance to two recipients.
In this case, a double spending attack is impossible given the design of FUSUS. In Fusus, once a user sends a certain amount to another address, the exact same piece of the amount cannot be sent to another address at the same time unless the first balance does not go through, or the balance increases with receiving blocks such that there is enough balance.
2. Wrong programming and poor network environment can also cause double spending.
Since the voting power is hidden to everyone and changes dynamically with respect to the population and participation, no single party will have enough confidence and motivation to vote otherwise. Besides, nodes get no financial gain for gaming the system instead are penalized for dishonest voting.
4. Sybil Attacks
To carry out a Sybil attack, a user creates many accounts with the intention of gaming the system and get more voting power. However, users are required to have a non-zero balance at all time in our system. This makes this action relatively expensive. Moreover, PoU consensus mechanism discounts the new stakes with the CST, AIST and LIST metrics, therefore, increasing the economic cost and discouraging such behavior in the first place.
5. Penny-spend Attacks
The Nano and IOTA networks have all suffered from a large amount of zero-value spam attacks. In Jura, this becomes impossible because of our VRF mechanism approach as opposed to the PoW anti-spam. Even if the attacks were to happen, the Fusus has a large capacity to absorb and consume a large amount of sending block thus resulting in zero or very little congestion.
To be specific, the PoVRT required to issue a sending block is designed to make it exponentially harder to issue an unreasonable amount of transactions, i.e., the first sending action since the last sending action or a threshold has zero time elapsing environment, however, the immediate sending actions will be forced to be separated by the VRFs. Again, the basic mechanism of sending blocks and PoVRT prevent this type of attacks.
So after reading this, we can proudly say that the Jura network is robust in the face of crisis and prepared to prevent any malicious attack that may hamper the performance of the network.
Did we miss anything? Let us know and we’ll be happy to answer.
Jura Proof of Dedication (PoD) Consensus Mechanism Demo
In this article, we’ll explain how our PoD Consensus Mechanism works. The links for you to actually try it out yourself will be at the end of this article. So let’s dive right in!
Proof of Dedication (PoD) Consensus Mechanism: Before going to PoD, let’s recap on PoU (Proof of Utility), which is a sort of credit score: a single value that describes the trustworthiness of an account by taking into account a range of different variables. In our creation of minebot, we have upgraded PoU to PoD to include the storage aspect. Our model thus far takes five different variables into account: the stake size, the age of the account, the average staking time, the last staking time and the storage size. Each of these variables is assigned a dynamically changing weight that will adjust itself in accordance to the system demographics. In a consensus mechanism, votes from an entity with a higher PoD would be weighted more than someone with a lower PoD.
In that sense, PoD is akin to a multidimensional, dynamic PoS, except one cannot game the system simply by controlling the majority of the stakes. Although we know which variables go into making a higher PoD, we don’t know what the weights of each one are, and furthermore, the weights will change over time. This effectively guarantees that no one will remain king of the hill.
So let’s start with the demo:
Let’s assume, you’re a node on the jura protocol. Now your ranking on the network will be dependent on four metrics:
Storage Size
Stake Size
Time spent on the platform
Average time between consecutive stakes
Last Staking Time
Now, let’s say your current stake size is 5, CST is 1.7, AIST is 0. Your current PoD score will be 0.1
Let’s say we vote with more stake size (greater than 5).
You can see your overall score automatically increases. Now if you keep on voting with hire stakes without spending a lot of time in between your votes, your PoD score will increase relatively quickly.
As you can see, the higher your stake size without skipping a voting turn will bring your PoD score very close to 1 which is extremely high.
But now, let’s say you do not participate in voting for the next five rounds, this will have a huge effect on your PoD Score.
Now you can see that the LIST is also in action which is the last time since you voted with a stake and your score automatically drop but 0.3 points.
But then if you decide to keep on voting/participating but with a relatively lower stake size, that will have a negative effect on your overall PoD score.
As you can see, the PoD score automatically drops like a lot. This is to make sure that nodes on the network are unable to game the system by voting in higher-amounts but with less stake size.
As there are more rounds in which users participate, the calculation of the score becomes more and more complicated. The key to a higher PoD score is consistency and higher rate of participation with higher stakes on the platform.
PoD will ensure there is no gaming of the system and will completely eliminate the possibility of 51% attack or penny attack because, at the end, the PoD score is highly volative and strongly co-related with the positive effort of the user.
We hope you were able to get an idea of the how our PoD will work at the backend and will ensure the authenticity of the protocol.
Now, it’s time for you to try it out yourself. Follow the link and explore our PoD: https://jura.network/pod
Jura Progress Update — Testnet 1.0 Version Release
Testnet Version 1.0
Technology Development
1.1 Release Testnet Version 1.0
Version 1.0 includes the Jura Explorer and a new version of Jura Wallet. This release is open to the public and the Jura community has been very interested in participating in this beta.
1.2 Jura Wallet
· Multilingual support
· Support Check-in, Dice and other small activities
· Restore some important UI bugs
· Fixed a bug where the mobile could not create an account
· Added Settings page
· Beautify the interface
· Refactoring the code to make it cleaner
1.3 JuraJ — Main Chain
· Simplify the process of account creation and login, and optimize the user experience
· The common code is modularized to facilitate SDK development
· Config module is implemented to support user configuration of running parameters
· Support check-in, dice and other small activities
Testnet Version 1.0
√ The JURA public chain testing network recently released Testnet Version 1.0 for external testing. Version 1.0 includes the Jura Explorer and a new version of Jura Wallet. This test is JURA’s future infrastructure for a decentralized ecology.
√ Jura Wallet has improved the interface and some basic functions, including Create Account, Restore Account, View Transaction Records, Sending/Receiving Transactions, and View Data. In addition to the basic functions, Jura Wallet has added some interesting functions such as Check-in and the Dice to enrich users’ experience.
√ Open the personal wallet interface, you can you can click Check-in, and there will be rewards for daily; and click on the Dice, which number you roll and you will get different proportions of rewards. In addition to the big rewards, there are fun experiences.
Smart Contracts in Jura Protocol
Smart contracts are very popular nowadays but what are they and what problems do they solve?
The term smart contract was first used by Nick Szabo in 1997 long before Bitcoin was created. He is a computer scientist, law scholar and a cryptographer, but in simple terms he wanted to use a distributed ledger to store contracts. Now smart contracts are just like contracts in the real world. The only difference is that they are completely digital. In fact a smart contract is actually a tiny computer program that is stored inside of a blockchain.
Let’s take a look at an example to understand how smart contracts work. Everyone is familiar with kickstarter. The large fundraising platform. Product teams can go to Kickstarter create a project set a funding goal and start collecting money from others who believe in the idea. Kickstarter is essentially a third party that sits in between product teams and supporters.
This means that both of them need to trust Kickstarter to handle their money correctly. If the project gets successfully funded, then the project team expects Kickstarter to give them their money. On the other hand supporters want their money to go to the project, if it was funded or to get a refund when it hasn’t reached its goals. In both the cases, product team and its supporters have to trust Kickstarter.
But with smart contracts we can build a similar system that doesn’t require a third party like Kickstarter!
So let’s create a smart contract for this. We can program the smart contract so that it holds all the received funds until a certain goal is reached. The supporters of a project can now transfer their money to the smart contract. If the project gets fully funded the contract automatically passes the money to the creator of the project and if the project fails to meet these goals then the money automatically goes back to the supporters. Pretty awesome right? And because smart contracts are stored inside a blockchain, everything is completely distributed. With this technique, no one is in control of the money.
But why should we trust the smart contract? Well because smart contracts are stored on a blockchain, they are immutable and distributed. Being immutable means that once a smart contract is created, it can never be changed again. So no one can go behind your back and tamper with the code of your contract, and being distributed means that the output of your contract is validated by everyone on the network. So a single person cannot force the contract to release the funds because other people in a network will spot this attempt and mark it as invalid.
Smart contracts can be applied to many different things not just on crowdfunding. Banks for example could use it to issue loans or to offer automatic payments. Insurance companies could use it to process certain claims and post the companies could use it for payment on delivery and so on and so on. So now you might wonder where and how can I use smart contracts? Well right now there are a handful of blockchain projects who support smart contracts.
In Jura, the smart contract implementation is easy and natural. Like I mentioned before, users using the Jura platform can create smart contracts to define transactions terms, save themselves from fraud or make sure the money transfer is transparent. Unlike other DAG structures, the smart contract implementation in Jura is ordered and the response time is fast which makes the smart contract implementation much more powerful.
Delving into the FUSUS — The data structure that will transform the world
As we are seeing an increasing interest in integrating Blockchain technology into our daily business operations, we see a parallel need to create a system that is scalable, reliable, and fast.
To fulfil this unmet need, Jura has invented the FUSUS, a data structure that is a multiple inheritance of blockchain, block lattice, and directed acyclic graph (DAG) technology. The FUSUS is a flexible, practical, and scalable data structure that provides us with the ability to achieve scalability, fast transactions, lightweight, and instant confirmation all at once.
Before we move onto introduce the concept in more depth. There are two main underlying concepts that we need to understand: the FUSUS account, as well as the transactions themselves
1. Accounts
An account is the public-key portion of a cryptographic signature key-pair. The address is derived from the public key, which is shared with the entire P2P network, while the private key is only known to the account holder. In traditional blockchain technology, an account can create a transaction and send the transaction to the target address, but does not store its own history. This leads to several problems:
- Error-prone account balance
- Lower security, especially increasing the risk of Sybil attacks
In Jura’s FUSUS data structure, each account is allowed to hold, store, and keep track of its own transactions. It helps to keeping track of the balance in each account that not only guarantees faster offline retrieval, but also makes the balance less prone to error. Because each account is initiated with a genesis block with a non-zero balance, the system is significantly more resistant to Sybil attacks. Any changes to the FUSUS on each account will require the account’s private key, thus adding additional layer of security.
2. Transactions
A transaction is any transfer of value from one address to another. In traditional blockchain, a transaction is viewed from a relatively high level and is considered as one single action from A to B. What differentiates JURA from traditional blockchain is the separate treatment of sending and receiving transactions. In the JURA protocol, sending and receiving transactions are treated differently due to their different processing time requirements. Sending transactions (ST) have a sense of urgency in them, since there must be sufficient balance in the account to make that transaction happen. Receiving transactions (RT) on the other hand do not have time urgency, and it is possible to have multiple RTs at the same time, whereas many incoming ST’s will cause a strain on the system. Treating these two transactions separately will help us be more efficient and achieve a higher level of transactions per second, or TPS.
FUSUS — Data Structure that will transform the world
Now that we have the basics down, let’s delve into the FUSUS itself. The FUSUS is essentially a DAG-lattice. This essentially means that the transaction histories of accounts form the lattice, and the history of each account is constructed by the DAG. In simple words, when the traffic volume is low, the DAG is effectively reduced to a blockchain structure, but when the traffic volume is high, the RTs form a DAG, and every ST plays the role of a new genesis block.
The process of formation is fairly simple:
1. Genesis block records the initial balance
2. Receiving block comes in either low or high traffic conditions, creating a narrow or a wide FUSUS
3. The initiation of every ST rehashes the FUSUS transaction history into a single node. This takes into account all of the confirmed receiving blocks and calculates the net balance after accounting for the balances in the receiving blocks
4. The send block is then inserted into the receiving DAG as a new genesis block. The number of confirmations of existing receiving blocks remains unchanged
5. The unconfirmed receiving blocks will keep growing the DAG and the process continues
What if there are no STs to initiate the formation of new genesis blocks? In the occasion should no STs be initiated within a certain timeframe (customizable to different applications), a new genesis block will be created for the user account, and all prior receiving blocks rehashed as usual.
In summary, the FUSUS gets us a whole range of benefits that we can leverage.
1. Transactions are attached algorithmically according to traffic volume, thus making the entire process highly efficient
2. Pruning of transaction histories helps save storage and increase lookup efficiency
3. Scalability is enhanced with unmeasurable potential peak
4. High TPS levels can be achieved without putting significant strain on the system
The Jura Team
Telegram: https://t.me/juranetwork
Twitter: @juraprotocol
Jura is defining the future of blockchain and we want you to be a part of it
So share this article and don’t forget to follow us on our social media to stay updated!
AI in Blockchain — Jura’s Security Layer
AI & Blockchain — Jura
AI is a very hot topic right now. Almost, every company has accepted that investing in AI is the only way forward if it wants to maintain a competitive advantage.
Before moving forward, let’s settle on a single definition of AI for the sake of uniformity. AI is an umbrella term for all processes that allow machines to act more independently and efficiently without human input. The AI-based algorithms take in a large amount of data, identify intricate patterns and apply the learning in various business applications like speech recognition, self-driving cars, and security. These algorithms work just like a human brain: with more information, these algorithms get smarter and better. Their overall error decreases and their prediction accuracy increases.
Jura is applying AI in its security layer. There are two major applications of AI in Jura.
1. Transaction Filtering
To protect Jura’s platform from fraudulent transactions, AI-based models will intake the transaction data and look at multiple variables like timestamp, balance, etc to identify patterns and predict a probability of whether or not the transaction is fraudulent. If the transaction is considered to be fraudulent, the sender’s account is soft-locked until the transaction details are justified. If the justification is confirmed, the soft-lock is released otherwise the account is hard-blocked and investigated.
2. Malicious Node Detection
The AI algorithms will also be collecting the system-wide node-level behavior data. This data will be thoroughly recorded and studied to identify any outliers or suspicious nodes. The idea is to prevent any malicious activity before it happens.
To achieve these two applications, we’ve divided the AI framework into three modules.
1. Online Logging Module
In this module, we will select features of transaction behaviors ( processed by each full node, and the full node behavior) and log them in each full node to collect training data. In the beginning, we will input fake transaction behavior and malicious nodes with labels. In the future, however, we will input human-reviewed data for training purposes.
2. Offline Training Module
We will gather data from each node, doing preprocessing and training models. With more incoming data, we will be updating our models to improve their forecasting accuracy and efficiency.
3. Online Serving Module
We will deploy and serve our models on two separate instances in the monitor layer. The first model, located in each full node, will detect abnormal transactions and the second model, location in the groups of monitors, will detect malicious nodes.
In short, Jura is taking the blockchain security to the next level by integrating AI and by identifying insights that current blockchain companies are unable to do. Jura’s platform provides a much safer ecosystem for users to transfer their funds without worrying about any security hacks. It’s a robust platform to host large-scale development projects.
If you enjoyed the article, don’t forget to clap and share it on social media! If you have any questions at all about the Jura Protocol, feel free to reach out to any of us! We’re always happy to hear from the community.
Jura’s home grown tech: Dynamic Monitored and Distributed Sharding (DMDS)
In the previous article, we learnt about the importance of sharding in the matter of blockchain scalability. We also learnt that the current implementation of the sharding technology had a two main drawbacks.
Security Threat
Issue of decentralization
Only after solving these two main issues, we will be able to make a scalable blockchain platform. In light of this, we propose the Dynamic Monitored and Distributed Sharding (DMDS) which allows the network to maintain its security while retaining its decentralization.
So let’s get right into it! DMDS is a concept from database partition: large databases into smaller, faster and easier managed shards. Due to space shortage issues, we divide the single Fusus (Jura’s data structure) into Fusus shards. Each shard contains different sub-Fusus which operate in parallel to achieve higher performance. There are two main reasons to do this:
1. As the number of clients in the system grows, the amount of information also increases exponentially therefore each node in Fusus will find it hard to store all the transaction histories
2. As traffic increases, the frequency of compression and new generation will increase dramatically which will lead to high timing and maintenance costs.
There are three core layers in Jura’s sharding architecture.
Router Layer
The router layer has m-routers in it. Whenever a request comes in, the router directs which shard will entertain the request. Each router contains two similar hashmaps:
Illustration of the Router Layer
The special client sharding is the key of special client shard and its value is real shard address. When a request combines in, the validator checks whether the key in the map or not. If it’s in the map, the request is routed to the shard automatically otherwise request is passed to a general client shard map. The key of general client shard map is shard index, value is the real shard address:
shardIndex = hash(sharding key) * mod(the num of shards)
Sharding Key helps to identify which shard the transaction belongs to. For example: “transaction_id”. The only issue with this is the double spending problem but to make sure double spending checking works, the addresses themselves can also be used as keys. In this way, all the transaction from the same address hash range will fall in the same shard and the checking will be done inside the shard as per regular operation.
Validation Cache Layer & Transaction Flooding Defender
In this layer, each shard has a validator which makes sure the request contains the correct info or not.
However, in the current landscape, transaction flooding attacks happen occasionally. Therefore, Jura has added a cache module to each validator. If the address hash in a request is in the validator, the validator rejects the request otherwise directs to the shard.
Each cache is designed using the LRU (least recently used) algorithm. In this process, a queue is maintained which contains all the transactions request in time window T. Each node in the queue is a pair (address hash) and the head pointer of the queue is check every second and removes the least recently used node if its expired.
When a new request comes in, the validator will check whether the address hash has been in the queue or not. If not, a new node which only contains the pair will be created and added to the tail of the queue. If the address has already been in the queue, it will be moved to the tail, and the timestamp in the pair is updated. For example, if the time window T is 3 seconds:
LRU (Least Recently Used) Algorithm
It is possible that a lot of requests comes to the validator at the same time, but since the validator only keeps the very small address and timestamp, the queue can be stored in either cache or system memory.
This LRU cache will be able to handle transaction flooding attack-type problems. When this type of attack happens, only the first request will be accepted, and other will be rejected and wait for T seconds.
Monitor Layer
This layer contains multiple monitors, each of which is defined as a group of coordinator nodes in the same shard. Each monitor will oversee the general info of the shard. Sometimes, even though sharding transaction request is done using address as sharding key, the storage space and CPU that a single node uses are still not that affordable because those requests can be spread evenly. Some addresses will inherently be much more active than others. As a solution, monitor layer will be added to fix this issue. Regular node staking will be selected as the coordinator, who gets incentives based on the bid rate of the overall shard groups. Each monitor server has three models.
Illustration of Monitor Server
Storage space and a CPU hacking model will check currently shard storage space and CPU resources used for nodes. If it is the above threshold, compression will be triggered and a new genesis will be built and the top active client addresses will be identified. the system would then add their addresses to a special client shard map in the router layer for router updating. After updaing the router layer, those special clients would be routed to some new backup shards with less traffic and fewer account addresses. Since traffic and users in this shard are far less as compared to be a normal shard, Penny-spend attacks can be afforded in those backup shardis by doing regular compression each time to save storage space.
This all sounds very technical and theoretically it is extremely sound. The interlinked functionalities of these three layers make sure the security is upheld and the network remains decentralized but not letting the nodes exceed their limitations. Following this methodology, we can ensure that we can create a much more scalable blockchain platform. Now the readers might still have a few more questions about how different shards will communicate with each other? What about if the number of shards get imbalanced? Also, what about the issue of full-node functionality?
Don’t worry, we have that covered too!
- Cross-shard communication
We’re aware that even though the transactions from a sending address will always be directed the same shard, sometimes the destination of the receiving end might not be the same. The solution is to find the receiver account’s shard and send an update request. If the updating is successful, the sending account is then updated otherwise it returns an error and asks the user to try again.
- Full-node selection
This is fixed and controlled by the monitor layer. When the monitor layer finds out that some full nodes are not functional, it will automatically add new full nodes to the shard.
- Shard-number imbalance
The number of shard, in the beginning, will be fixed but when the traffic exceed the limit for more that half of the nodes, a new shard is created and half of the requests are directed to the new shard by dividing the hash range of original shard into two equal ranges.
DMDS seems like the only way forward as it’s flexible, secure and upholds the decentralization status of the entire network!
Thank you for reading. If you liked the article, clap and share!
Blockchain Basics: Sharding Technique
Traditional Sharding
Background
Scalability is one of the biggest problems that many blockchain platforms face today. Scalability is the sole reason why we haven’t seen a big breakthrough in the adoption of the blockchain. In fact, public blockchains like Ethereum handle only up to fourteen transactions per second on average, and this figure is far inferior in terms of real-world business transactions.
Slow transaction processing has the potential to choke up the network and take us far away from real-time sharing of information that is extremely vital in today’s competitive and data-driven world. The inconvenience factor increases by three with a minute-increase in confirmation time. Unless we solve the TPS problem, we will not be able to host complex DApps on the current network and pave way for the global adoption of the blockchain technology.
So in light of all these issues, what technique should we use in order to solve this TPS problem?
Solution?
One widely accepted solution is Sharding. A shard is basically the horizontal portion of the database which is stored on a separate instance on the server. This concept of sharding is taken from traditional databases in which the main idea is to distribute information in shards (smaller databases) to spread the data and process information more efficiently and quickly. Sharding also allows for faster data transactions because when you spread the information across multiple databases, each smaller database can process specific information at the same time as others. Therefore, the more shards you have, the more information you can process in parallel.
However, the process of sharding in Blockchain is comparatively complicated since basic consensus mechanisms like Proof of Work require every node on the network to carry all the information. The only reason PoW is still used in blockchain is because of its high security and accurate validity of the transactions. But this approach is not considered to be scalable.
On the other hand, most of the sharding techniques used are primarily in projects that employ the Proof of Stake consensus mechanism as opposed to the PoW consensus mechanism. PoS uses specific, designated nodes, with specific information that requires individual nodes to put tokens as stakes and take the responsibility of validating the transactions. Sharding has a big fan following in the Ethereum community but it remains unclear when an Ethereum sharding protocol might actually be implemented.
Benefits
That being said, sharding, in itself, has a very specific job description: blockchain sharding includes different nodes processing different transactions in parallel instead of involving all the nodes for information processing and validation. Sharding seems like a very practical solution for the blockchain scalability issue because the number of shards in the networks can scale infinitely without worrying about the scale of the network itself. This also means that the more nodes you have on the network, the higher your ability to distribute information across shards on the network and increase information processing speed without compromising the consensus ability.
Problems
Although sharding sounds very appealing and all-very-perfect, it is not without risks. Through extensive sharding, we run the risk of compromising decentralization and security. In a complete decentralized network, all nodes are involved in validating the transactions. However, when we shard the network, only specific nodes present on the shard are responsible for validating the transactions. Moreover, This increases the probability of invalid transactions recorded by a subset of malicious nodes and also increases the chances that a malicious node goes undetected thus compromising the network’s security.
Conclusion
In conclusion, sharding is definitely a promising solution to the scalability problem but can cause security and decentralization issues. Currently, there are several types of sharding techniques employed by many blockchain projects but no technique is adequate enough to solve the scalability issue. However, Dynamic Monitored and Distributed Sharding is one unique technique that is currently under-development but theoretically is the perfect solution for the scalability problem.
JURA Bounty Program 2018
Dear Jura Fans,
Are you ready to be a bounty hunter and win a lot of cash?
Summertime sadness kicking in? How about we help you with….280,000 Jura Tokens!!
There are many ways to earn rewards, so pick any one that goes best with your strong suit and roll with it!
Users are allowed to make unlimited numbers of entries to the program, so long as all the rules are followed. Keep in mind that all submissions must follow all steps in their respective categories in order to qualify for JURA tokens, and please, all inappropriate or obscene posts will be instantly disqualified. Winners will be selected by the JURA team based on the explanation, number of likes, shares, and creativity of the submission.
Sign up now at https://jura.bounty.global and start hunting.
Starting Date: 30th August 2018
Ending Date: 6th September 2018
Videos
Overview:Choose from the following list of concepts, and make us a quick video
(less than 2 min 30 sec) explaining a topic from the list below.Concepts to choose from:
— FUSUS data structure
— Distributed ledger technology
— Broadcasting & validating algorithms
— PoVRT anti-spamming module
— PoU consensus mechanism overview
— PoU consensus comparison to PoS / PoW
— Dynamic Monitored and Distributed Sharding (DMDS)Instructions and qualification criteria:
1. Follow the JURA Protocol on Twitter / Telegram / Medium / Instagram
2. Take a short video no more than 2 minutes and 30 seconds. Make sure to provide an introduction of who you are and where you come from.
Example: “I’m [name] from [country / city / company] and I support JURA because [reason]. Here is a quick explanation of JURA’s [insert concept] in a few minutes!”3. Post the video on YouTube
4. Share the video on your own Reddit, Twitter, Instagram, and / or Telegram page, and tag at least 5 friends, along with @JuraProtocol
Rewards
The video with the most likes and shares will win 40,000 JURA tokens. The JURA committee will also decide on the best video based on concept explanation — that winner will also get 40,000 JURA tokens. Note that it’s possible to be the winner of both categories.
Articles
Overview:These are informative articles to be published on Reddit, Medium, or Telegram. We haven’t specified the length or technical level of your written piece, so this aspect will be left up to you to decide on. The more detailed, the better however.
Concepts to choose from:
— FUSUS data structure
— Distributed ledger technology and JURA’s competitive advantage in the market landscape
— PoVRT anti-spamming module
— PoU consensus mechanism overview and comparison to PoS / PoW
— Dynamic Monitored and Distributed Sharding (DMDS)
— Potential commercial applications of the JURA protocol
— Five reasons JURA is one of the strongest crypto projects of 2018Instructions and qualification criteria:
1. Follow the JURA Protocol on Twitter / Telegram / Medium / Instagram
2. Write an article on one or more of the aforementioned topics
3. Post and share the article on your own Reddit, Twitter, Instagram, and / or Telegram page, and tag at least 5 friends, along with @JuraProtocol
Rewards
The article with the most likes and shares will win 35,000 JURA tokens. The JURA committee will also decide on the best article based concept explanation — that winner will also get 35,000 JURA tokens.
Pictures, Selfies, and Memes
Overview:Are you a selfie boss or Photoshop master? Or do you have a passion for photography and art? Take a picture or selfie and tag us in it.
Instructions and qualification criteria:
1. Follow the JURA Protocol on Twitter / Telegram / Medium / Instagram
2. Take a picture or selfie, or create a meme involving JURA. For pictures and selfies, include a JURA-related caption with either #jura, #jurasaur, or #jurasaurusrex
3. Post and share the picture, selfie, or meme on your own Reddit, Twitter, Instagram, and / or Telegram page, and tag at least 5 friends, along with @JuraProtocol
Rewards
The picture, selfie, or meme with the most likes and shares will win 20,000 JURA tokens. The JURA committee will also decide on the coolest or funniest picture, selfie, or meme– that winner will also get 20,000 JURA tokens.
Other (Sticker Sets, Music, Code, etc.)
OverviewThis is an open ended competition, so if you’re a musician, an expert coder, or someone who just loves making new Telegram stickers, here’s your chance to shine.
Instructions and qualification criteria:
1. Follow the JURA Protocol on Twitter / Telegram / Medium / Instagram
2. Make some form of media involving JURA. Include either a JURA-related caption with #jura, #jurasaur, or #jurasaurusrex where applicable
3. Post and share your creation on your own Reddit, Twitter, Instagram, and / or Telegram page, and tag at least 5 friends, along with @JuraProtocol
Rewards
The user with the most likes and shares will win 20,000 JURA tokens. The JURA committee will also decide on the coolest or funniest media piece that doesn’t quite fall into the three previous categories — that winner will also get 20,000 JURA tokens.
Recruitment
Overview and rewardsIntroduce people to the JURA family and get rewarded! The user who manages to bring the most members onto the Telegram channel will earn 30,000 JURA tokens, while the second place user will earn 20,000 JURA tokens. Note that we will be actively scanning for bots here, and we reserve the right to disqualify users for any reason.
Good luck!
The Jura Team
DAGs — Not Blockchain, but better?
A topological ordering of a directed acyclic graph: every edge goes from earlier in the ordering (upper left) to later in the ordering (lower right). A directed graph is acyclic if and only if it has a topological ordering [Source: Wikipedia]
Although, a large number of blockchain technologies are underdevelopment, the current publicly available blockchain solutions are still at the exploratory stage. Unfortunately, no single blockchain technology is able to provide large scalability, fast finality and strong reliability simultaneously. One way to overcome these issues is to use DAG as an underlying data structure. It has found promising applications in many fields, such as scheduling, data processing networks, causal structures, data compressions etc. So what exactly is a DAG?
In a nutshell, blockchains are cryptographically verifiable single linked lists. A DAG is a different type of data structure. DAG stands for Directed Acyclic Graph. It’s an implementation of Graph and allows networks using it to circumvent some of the blockchain’s most daunting limitations like lack of scalability, flexibility and finality. In a DAG, all the nodes point in the same direction, thus acyclic, and no element can reference back to itself. It’s a data structure that only allows one-way flow of information. It’s mostly used in problems relating to data processing, scheduling and data compressing.
Due to the inefficiencies in the Proof-of-work(POW) and the Proof-of-Stake(POS) systems, it becomes difficult to reach a higher level of transactions per seconds that hampers the global adoption of blockchain as a technology. No one wants to spend 10 minutes just to pay for coffee! So DAG powered networks allow appending parallel running nodes as long as everything flows in the same direction.
Using DAG has a lot of benefits:
1. Quick transactions
Due to its blockless nature, the transactions run directly into the DAG networks. The whole process is much faster than those of blockchains based on PoW and PoS.
2. No mining involved
In a DAG system, there are no miners and there are no blocks, users confirm each other’s transactions via a process that confirms previous transactions with each new transaction. Because there are no blocks, there is no block size issue and therefore, the block scaling debate seen in currencies such as Bitcoin does not exist.
3. Friendly to small payments
With the advancement of DAG, we’re looking at a future where high functioning and minimum transaction fee chains are possible. That means users can send micro-payments without incurring heavy fees like that in Bitcoin or Ethereum.
Technology built on DAG has the potential of handling a very large number of transactions per second. DAG will be used for applications that require scalability in the thousands of transactions per second.
Although, DAG is very flexible data-structure, it still has a lot of drawbacks.
1. No Global State
In Blockchain, every node is able to cross-check transactions against ledger history and can also check against the threat of double spending. However, as DAG follows a transaction-by-transaction approach, no global state exists. As the size of database increases, pruning is necessary but it’s basically taking a snapshot and enabling nodes to delete all transactions prior to that which is not optimal at all.
2. Double Spending
We can try solving this by sharding but while all shards still operate to the same protocol, they now only see parts of the ongoing transactions and associated history which causes a number of issues. Firstly, preventing double spending becomes difficult. For example, consider the DAG is split into ten parts and transaction is on the strongest tip of two of these shards. Unless there is a node that has the signt of both shards, the transactions will validate each of the two shards, thus causing a double spend.
3. Higher Costs
This issue becomes more prevalent as the DAG scales. The more shards there are, the less overlaps. The simple solution would be for all nodes to have to contact each other for each transactions they see but then costs will be the same for each node as all nodes will simply hold the entire DAG.
4. Vulnerable to Attack
DAGs are vulnerable to attacks which is due to the lack of constant mining and also because malicious actors only need to gain over 33% of the total hash power to be able to attack the network even before the network is sharded. In a DAG, decentralized security is traded for performance. One of the main selling points of Bitcoin was that it was a distributed network spread worldwide but a limited number of nodes in a DAG are much easier to attack than thousands spread worldwide.
5. Do not Guarantee & Secure Timestamps
DAG’s do not guarantee and secure timestamps which causes double spending and makes it difficult for applications built to run on the DAG that require an exact timestamp.
DAGs are capable of scaling beyond current blockchains. But just as blockchains have limitations on how much they can scale, so do DAGs. So the question arises that what is the best data structure to use in order to pave way towards a global adoption of blockchain?
Find that out in our next article. Follow us on Twitter to stay updated.
Anything we missed or you would like to add? Please let us know through Twitter, and we’ll feature your article in our community blog!
Introducing the JURA Protocol
With the recent rise of dapps and token economics, the blockchain technology landscape has been constantly evolving to reveal newer technologies designed to facilitate the transfer of goods or execution of smart contracts in a decentralized manner. However: the speed and efficacy of dapps and smart contracts are fundamentally limited by the underlying blockchain protocol. Typically, when we think of decentralization, there’s a tradeoff: with increased security and decentralization come lower transaction speeds.
But why can’t we have our cake and eat it too?
With this in mind, we’d like to introduce the Jura Protocol: a paradigm-shifting suite of four technologies that together form the foundation for a robust new blockchain ecosystem. No longer do we have to worry about such a sharp tradeoff between finality and decentralization, but can have a system that can fully realize the potential of blockchain technology while still supporting all of the dapps and smart contracts that we know and love.
The Jura protocol is feeless, ultrafast, and provides the decentralized security required for users to rest certain that their transactions are safe.
What is Jura?
Again, Jura is a suite of four different technologies coming together to make a new blockchain ecosystem.
1: Fusus data structure
The Jura protocol is designed to treat sending and receiving transactions differently, with each individual user’s account forming a directed acyclic graph, or DAG, to boost system speed. With each sending transaction, the entire user’s transaction history is rehashed into a single new genesis block, thus effectively pruning the DAG, increasing lookup efficiency, and furthering system speed. The cyclic outward growth and subsequent fusing of information into a new genesis block unique to our system led to us name it the Fusus data structure. To prevent spamming and double-spend attacks, we’ve implemented a proof of verifiable random time (PoVRT) module with each sending transaction: each successive spending transaction will have to wait a pre-appointed, system-distributed, random amount of time before being posted to the consensus.
2: Proof of utility
Proof of stake (PoS) and proof of work (PoW) consensus mechanisms have been proposed and used previously in other systems, but are vulnerable to attacks from malicious users. In the PoS model for example, if I were to buy more than 50% of the stakes, I would be able to control the voting for the system. For our consensus mechanism, we have designed an entirely new framework called the proof of utility (PoU) system to validate transactions.
PoU essentially functions like a traditional credit score, or a multi-dimensional, evolving proof of work mechanism: we know the factors that go into establishing a good credit score, such as paying your bills on time and not defaulting on any loans. However, the exact formula in determining our credit scores is not well known. In our PoU mechanism, we take in account factors such as the age of the user’s account, the average interstaking time, and the last staking time, in addition to the size of the stake itself, in order to obtain a more accurate measurement of the trustworthiness of a vote: all votes are then weighted by their respective PoU scores. This way, a user cannot simply buy voting power (PoS system), and since the translation from user factors to PoU contribution is non-linear and bounded between 0 and 1, a user cannot boost his or her PoU score by focusing all of his or her efforts into one variable.
Most importantly however, users cannot game the system since the weights associated with each of the variables evolve over time: as the system demographics change, so do the weights. The adjustment of system-wide PoU weights and calculation of individual PoU scores, which will happen at regular time intervals on the order of days, won’t take much considerable computing power at all, but will serve to provide a lightweight, effective framework for ensuring a fair consensus.
3: Dynamically monitored and distributed sharding
Sharding then allows clusters of nodes to work together to form a local consensus, thus striking a balance between decentralization and speed. In our system, we use a multi-layered dynamically monitored and distributed sharding (DMDS) technique to enable parallel processing of requests and ensure that if a node gets dropped, it will be quickly rerouted to another active shard. In here, system storagers provide data storage to facilitate transactions, individual shards are overseen by a single monitor, and finally, a panel of high PoU value judgers functions as an arbitration committee should transactions be flagged as suspicious.
4: AI security layer
Finally, the incorporation of AI security and machine learning will allow our system to automatically flag malicious behavior and nodes as time goes on. Although this would be primarily an offline module in the first few years, over time, this feature will become more and more autonomous with increasing accuracy.
Jura Token Economics
In order to ensure a robust token economy, Jura has ample system rewards for catching malicious activity, providing storage, etc. And rest assured, we have enough system rewards to ensure for the functionality of the system for the next fifty to one hundred years, accounting for inflation and system growth. The system will also penalize dishonest nodes with staking penalties as well as penalties to the user’s PoU score. Due to the construction of the PoU mechanism, there is little to zero economic incentives for malicious parties to initiate attacks, as revealed by game theory analyses and our comprehensive attack scenario simulations. Finally, this system is customizable to different industries and applications: while we intend to debut our system with IoT applications, the range of applications this system can tackle spans from medical records to finance to education to law.
For more information on this project, please consult our white paper over at https://www.jura.network/. If you have any questions at all about the Jura Protocol, feel free to reach out to any of us! We’re always happy to hear from the community. Also, we’re hiring, so if you think you’d make a community manager or become a part of our engineering or marketing teams, send us an email at contact@jura.network
