The first month of summer and the last month of quarter two 2019 has been busy as usual for the Insolar team. Plenty of travel, new hires and the release of our economic paper. Of course, the development team have been hard at work readying the Insolar Blockchain Platform for MainNet launch at the end of September.

The long awaited Insolar Economic Paper was released at the end of June and highlights how Insolar native tokens shall be used to support the economics of the MainNet ecosystem. Meanwhile, INS tokens were listed on Bithumb Global, one of the world’s leading cryptocurrency exchanges.

1. Community

Announcements

The Insolar team participated at the Crypto Valley Conference on Blockchain Technology 2019 in its hometown of Zug, Switzerland. The conference covered topics on technology, economy & finance and legal & regulation in the blockchain sphere, with attendees from the EU Commission, the Swiss National Bank, the WTO, along with representatives from IBM, Ethereum and Microsoft.

Insolar headed to the Blockchain Summit London 2019 in the UK to speak and present its vision for blockchain. Among the attendees and other speakers included representatives from the Bank of England, PwC, KPMG, Oracle and SAP.

Insolar Listed on Bithumb Global

Insolar’s INS tokens were listed on Bithumb Global, a leading digital asset exchange platform worldwide. INS tokens are also available for trading on other major exchanges, including Binance, Okex, Kucoin, and others.

Insolar has released its economic paper, highlighting the token model for XNS, the native token for Insolar Blockchain Platform. The paper highlights several aspects of how the token will be utilized within the platform to support blockchain business ecosystems on Insolar. The premises of the paper are built upon the vision that the Insolar team set forth in its tech paper, which was released at the start of the year.

Top Tech News

Top Articles

Blockchain shows much promise, but enterprises and businesses are so far hesitant to adopt this technological innovation. One of the main reasons for this is the risk of vendor lock-in, whereby data is not transferable to other systems should the company wish to switch. Insolar is creating a platform that is interoperable with other major distributed ledger technologies (DLTs) to foster wider adoption of the tech. Read how in this tech article.

Blockchain: Crossing the Adoption Threshold

Blockchain platforms are closing in on the point of adoption, with a recent Deloitte report from organizations surveyed indicating a ten percent increase in blockchain implementation being amongst their top-five strategic priorities. If the stats aren’t enough to convince you that blockchain adoption is on the horizon, then maybe the hype is. Learn about how Insolar will bring about adoption through its next generation tech.

Hybrid Networks: Covering All Bases

Distributed ledger technology (DLT) networks are usually split into camps: public and private, permissionless and permissioned. The degree of network openness often depends on the utility of the DLT, with more closed networks said to be more suitable for business in order to keep their data secure. But what happens when enterprise needs to hold some parts of its data secure, yet share other parts with other counterparties or the public at large? Insolar Blockchain Platform is able to segregate data and link different networks with different utility to bring about the much needed network effect blockchain has been waiting for. Read to learn more.

2. Engineering highlights

The App Logic team worked hard to make sure the trace identificator is completed by the network and so that the proxy generator for contracts now guarantees a declaration for order of types. Moreover, Virtual nodes now tell the requester to retry calls to objects where Pulses change and nodes don’t have the right to execute this to the object anymore and several goroutine leaks have been removed.

The Insolar developers also made sure that if a node redirects a message to another for execution, the initial caller node of this message is defined as the Sender, not the node which redirects the message. In addition, redirected messages now have the same message ID across nodes when redirected.

The Business Services team completed migration daemon QA uncovering and fixing all bugs, plus they updated the API requester due to API interface changes. The team also created an application for calling smart contracts using a new API mechanism. Moreover, migration Daemon functionality has been improved. Transaction support with multiple receivers, restart from the last block delivered and blocks with a huge number of transaction functionality are now possible.

That’s not all: Pulse ending procedures have been created for the heavy material node (HMN) replication mechanism. This makes certain that all current Pulse data is transferred from light material to heavy material nodes. Plus, a HMN data integrity check has been added, meaning we can now identify and correct any mistakes or add data where it is insufficient.

The Ledger team improved Jet calculation stability and introduced a Filament iteration prototype, meaning objects can now have many iterable entities (such as requests). This team also worked hard to implement Async messaging for object and code fetching.

The Smart Contracts team have made parallel execution of immutable calls possible. All method calls on a single object must be executed sequentially to prevent concurrent modification of the object state. We have implemented parallel execution of such methods. If the contract method is annotated as “immutable”, call requests to this method are not added to execution queue; instead they are executed immediately.

Built-in contracts have now been added to the platform. This is a new smart contract architecture and the code of these contracts is a part of the platform itself. Built-in contracts work faster and produce less load on the platform than ordinary contracts. These contracts implement base functions that are required by other contracts, like authorization and user and node management.

3. Team

Vitaly Panteleev joined Insolar as a Front-end Developer

Vitaly has managed frontend development for the past 10 years, previously working for Finnish company Tsampomill. He mainly worked on fixing internal operations within the company and introduced unit and end to end testing processes in frontend.

_______

Check our Github and leave feedback on the code.

Follow Insolar on social media: