OWASP formally introduced ASI:10: Rogue Agents in its Top 10 for Agentic Applications released in December 2025 — their ranking on the top 10 security risks for agentic AI applications.

The attack surface outlined in that list marked a significant shift compared to the OWASP TOP 10 for LLM Applications: except for LLM06: Excessive Agency, all the listed LLM security risks focused on the input/output that a model receives/produces, whereas the Agentic Top 10 focuses on what happens when those I/O become actions handled by autonomous or semi-autonomous systems.

AI agents can now browse the web, execute code, use credentials and interact with real infrastructure. A bad model output no longer necessarily ends with a bad answer: the blast radius is far larger and not as easy to map to a deterministic threat model.

However, it wasn’t until 2026 that rogue agent incidents moved from rare edge cases to a visible and rapidly growing security threat.

What is a rogue agent?

Rogue Agents are malicious or compromised AI Agents that deviate from their intended function or authorized scope, acting harmfully, deceptively, or parasitically within multi-agent or human-agent ecosystems

As per OWASP definition in its Top 10 for Agentic Applications for 2026.

The critical concept is behavioral divergence: autonomous systems can develop emergent behavioral properties that can become harmful and unpredictable.

An agent does not necessarily need an attacker to go rogue.

External compromise — prompt injection, goal hijacking or agentic supply-chain tampering — can trigger the divergence.

But so can internal misalignment: conflicting objectives, reward hacking, proxy optimization or simply an autonomous system progressively interpreting its objective differently from how its operator intended it.

This distinction matters because traditional security controls mostly verify whether an identity is allowed to perform an action.

Rogue-agent security, however, doesn’t fall under the traditional trust boundaries and threat models that we use to map software architectures, which brings to the hard question:

Is the agent still using those permissions for the objective we actually authorized?

Snyk describes this as a loss of behavioral integrity (or intent drift): individual actions can remain technically permitted while the overall behavior drifts outside the intended purpose.

That makes a rogue agent look less like traditional malware and more like an insider threat operating at machine speed.

Then the agents started acting

The OpenAI–Hugging Face incident is probably the most notorious example so far.

During cybersecurity evaluations in July 2026, OpenAI agents circumvented isolation controls, established unauthorized communication channels, gained internet access and compromised parts of OpenAI’s research infrastructure and Hugging Face’s systems while pursuing their assigned tasks. OpenAI later described the actions as misaligned with the goals of the assigned tasks and called the incident a “warning shot” for the industry.

The model did not just produce the wrong answer.

It acted.

Not so long after, some Anthropic models also went rogue.

Enter the Swarmchasers

New kinds of cybersecurity threats require a new kind of security researcher.

Researchers informally known as Swarmchasers comb the public web for traces left by autonomous AI agents and reconstruct what those agents were doing.

Unlike malware forensics, there is no stable executable to hash or cluster, so the conventional forensics/telemetry techniques are not as effective. The rogue agents activity is iteratively reconstructed by identifying behavioral/communication/traffic patterns, timestamps, payloads and shared infrastructure.

It starts to look like a new form of **agent threat intelligence**.

Traditional threat intelligence reconstructs:

malware → infrastructure → attacker

Agent threat intelligence may increasingly need to reconstruct:

agent → objective → tools → actions → infrastructure → behavioral divergence

The interesting signal is no longer just the API call, shell command or HTTP request.

It is the sequence of actions and the objective behind them.

If you’re interested in following more rogue-agent incidents, I’m tracking a growing dataset of autonomous security attacks on Rogue Agents Watch.

And you want more AI security, MLSecOps and agentic security research, check out The MLSecOps Hacker at themlsecopshacker.com

What Are Rogue Agents? Autonomous AI incidents and the Swarmchasers going after them was originally published in Rogue AI Intel: MLSecOps & AI Security News on Medium, where people are continuing the conversation by highlighting and responding to this story.

Curious how to get started with building on the Internet Computer? In this article, we will review some of the reasons why Motoko came to be, its trade-offs compared to the alternative ICP smart contract languages and, finally, how to dive into the syntax of Motoko right away on AgorApp — the go-to online interactive coding platform.

Introduction to Domain-Specific Languages

The landscape of domain-specific languages (DSL) specifically dedicated to smart contract development is growing. The reasons why the blockchain ecosystem has fueled the research and development of so many new domain-specific languages are plentiful.

A DSL offers many attractive features and trade-offs, especially in the context of Blockchain systems — where financial assets are a first-class citizen and, subsequently, the need for security and correctness is paramount.

However, let’s first define what a DSL is: a domain-specific language is a programming language that is designed to address very specific problems, platforms or domains. While languages like Javascript, Python and Golang are general-purpose and can seamlessly be used for almost anything, the design of a DSL is tightly coupled with the domain and challenges it is meant to be used for. The domain-specific design allows to achieve several benefits, such as:

• Enhanced security: by narrowing their scope, domain-specific languages can more easily integrate compile-time checks, safe type-systems and various forms of runtime protection and formal verification.
• Enhanced developer experience: similarly to the previous point, the narrow scope of DSLs allows to create abstractions and built-in that provide first-class access to the domain-specific features and functionalities.
• Enhanced performance: lastly, the highly specialized nature of DSLs allows to fine-tune the language for specific tasks in order to achieve better performance than its general-purpose counterparts.

The domain-specific language of choice in the Internet Computer ecosystem is Motoko.

Motoko is a statically typed language that compiles into WebAssembly. Its design leans towards the functional paradigm, but it equally emphasizes ease of use and smooth developer experience.

Some of its language features like pattern matching might already be familiar to those who played around with languages like Haskell, nevertheless the overall syntax is much more approachable than its functional counterparts.

The other main smart contract language in the Internet Computer landscape is Rust: unlike Motoko, Rust is obviously a general-purpose language.

Building on the Internet Computer is a decidedly different experience compared to developing on Ethereum. While the Ethereum’s EVM is a sandboxed deterministic execution environment, the ICP architecture is made of canisters — computational units that execute code and store data — which can host full-fledged web-applications, make outbound HTTP requests and so on.

In the context of ICP app development, Motoko offers some notable advantages over Rust. In this article we will go through them and you will also get to practice some Motoko right away on the AgorApp embeddable IDE.

But first, an interesting tidbit for all the cyberpunk and anime enthusiasts out there: the name Motoko is likely a reference to the main character of the Ghost in the Shell series, Motoko Kusanagi — highly recommended if you haven’t watched it yet!

Comparison between Rust and Motoko

The design of the Motoko programming language was tailored to easing up the asynchronous communication between different entities on the Internet Computer network.

The model upon which the Internet Computer is built is that of a distributed network of memory-isolated entities that communicate asynchronously with each other. These asynchronous messages use a lingua franca called Candid.
Candid is a language-agnostic interface description language (IDL) that allows different services to interface with each other without worrying about their respective implementation details — i.e.: a frontend is written in Typescript, another service is written in Golang and an ICP application is written in Motoko.

Now, asynchronous communication in a distributed system is a notoriously daunting engineering arena. As such, the Motoko language was designed using the Actor model, which is a computational framework/paradigm that allows to easily reason about different entities in a distributed asynchronous setting.
The main actor entity on the Internet Computer is the canister.

A canister is a memory-isolated entity that holds both compiled code and storage.

After being compiled into WebAssembly bytecode, Motoko programs are deployed to canisters, which then act as computational units that can be invoked by other canisters or by users via the Internet Computer’s IC SDK.

If you want to start dipping your toes into the Actor model and Motoko’s language features, you can check out the Learn Motoko course — it is geared towards beginners, but the last lesson Introduction to Actors touches upon the very concept.
Stay tuned and subscribe to the mailing list to be the first to know when we will roll out more advanced courses!

As powerful as Rust is, it is not designed with the Actor model and the ICP architecture in mind: Motoko provides native support for Candid, a strong type system which statically ensures the absence of dynamic type errors and, lastly, more intuitive abstractions for inter-canister communication.

Enough benchmarks for now, we will revisit the topic in a future article. Let’s jump right into the IDE.

Your First Motoko Coding Challenge & AgorApp embeddable editor

Want to try out your first Motoko coding challenge in our embeddable editor? Then click here to check the original blog article!

In the upcoming weeks, we will gradually roll out our web3 embeddable editor feature to various platforms (maybe medium? reach out to tell us which platforms you’d like us to support!) and partners — such as bootcamps, DeFi/blockchain protocols that want make their technical documentation interactive and selected content creators. Then, after the end of the triage, it will be made available to all our users.

if you are a tech/web3 content creator — Udemy, Youtube, blogger- and you’d be interested in integrating our embeddable IDE in your coding tutorials or creating a custom IDE instance for your audience so that they can better follow along your video courses, we’d love to hear from you. Our goal is to provide new ways with which you can engage your audience with the technical content you are creating.

You can contact us on AgorApp Discord or just touch base with us on Twitter or Linkedin.

About AgorApp

AgorApp is an online interactive coding platform that offers courses and challenges focused on all-things-web3 engineering: from web3 domain-specific languages to building on top of DeFi and NFT protocols, solving smart contract auditing challenges in a browser-based IDE or participating to gas golfing competitions.

With DFINITY and ICP, our core mission is to onboard the next wave of engineers into the developer ecosystem: from fast-tracking their programming training in Motoko and understanding of the ICP architecture to immediately recommending our users opportunities to monetize their newly learned ICP development skills right off the bat with grants and available job openings available in the Internet Computer ecosystem via our workspace dashboard.

Would you like to dig deeper into the product we are building at AgorApp? Check out our introduction article and sign up to the blog mailing list to not miss our next technical deep dives into smart contract engineering, Motoko, Internet Computer development & get notified about fresh job and grant opportunities before everyone else.

A Glimpse into Motoko and AgorApp embeddable IDE was originally published in The Internet Computer Review on Medium, where people are continuing the conversation by highlighting and responding to this story.

DeFi and CeFi: a tale of two worlds

One of the many lenses through which we can assess the maturity of the current state of DeFi is by ranking the volume of its financial instruments and then compare the findings to their CeFi counterparts.

As other analysts have already pointed out, the most significant disparity between traditional financial markets and the cryptocurrency market lies in the difference between the size of the derivative market and market share of spot assets.

While, in the traditional financial markets, derivative volume dwarfs equities and other spot assets by a multiple greater than 30, in the cryptocurrency market options are only a relatively thin slice of the pie.

The DeFi ecosystem has been so far a retail market largely dominated by spot exchanges. In hindsight, it was a logical trajectory as the mechanics underlying the financial primitives of spot exchanges are inherently more easy to implement than the financial wizardry required to concoct a derivative market.

However, as the rate of institutional adoption keeps increasing, the DeFi instrument volume ratio will start to mirror CeFi: this means a potential growth for the DeFi derivative market that could be many orders of magnitude.

The bottlenecks that have prevented the growth of the DeFi derivative market can be summed up in two main categories: technical and demographics.

If it is in large part true that the cryptocurrency market first started and then flourished thanks to its strong, diverse grass-root retail user-base, it’s also true that the same user-base has increased their financial literacy over time. In what has been a collective learning experience, it is likely that many of its zealous users — a.k.a. the degens — have become traders and, similarly, developers have become financial engineers. At the same time, the rate of adoption among institutional investors — hedge funds, corporations adding crypto-assets to their balance sheets etc.- has consistently increased over the past year.

To further prove the case, the volume of Deribit and other centralized cryptocurrency options platforms has witnessed an exponential growth in 2021: still not as high as their CeFi counterparts, but much higher than decentralized derivative exchanges.

So if the appetite for options of both users and investors is finally there and outmatches the current supply of financial products, then the only remaining reason for the current bottleneck in the DeFi derivatives market must be technical.

And if the bottleneck to a large extent is technical, how can we solve it?

This is the question that we, in the Opium community, wanted to solve with the design of Opium V2 and the new pool products that will soon be released on top of it.

The design dilemmas of a derivative protocol

Two of the top factors that determine the success of a DeFi derivative protocol are liquidity and flexibility.

Liquidity is essential for traders to ensure that there’s a market where they can exchange their assets. Flexibility is essential for financial engineers to ensure that a protocol allows them to seamlessly encode the financial requirements of their products: in other words, flexibility can be regarded as a good developer experience (DX).

Some protocol architectures, however beautiful and efficient for a specific use-case, tend to over-engineer their foundational layers, which ends up imposing constraints down the road in the breadth of products and financial requirements that they can support natively. One of the side effects of that is that the developers building on top of such an architecture will face implementation obstacles which will decrease the reach of third-party integrations.

Especially in an ecosystem such as DeFi, rooted in open-source development and governed by network effects, a software is only as strong as it is its adoption rate in the developer community.

The Opium protocol v2 is meant to be asset-agnostic, both in terms of supported underlyings and in terms of oracles.

It is intentionally minimalist in its set of assumptions about what a financial product traded on it should look like.

As such, the Opium Protocol v2 acts as a trustless settlement layer with escrow functionalities. Any kind of sophisticated business logic (options strategies, vaults, peer-to-pool with different AMM models, different types of products -call/put options, CDS, interest rate swaps-) is something that can be easily supported atop the protocol, but it is not explicitly encoded in its core contracts.

The responsibility of the protocol layer should be only to mitigate counterparty risk in a trustless fashion and ensure the internal consistency of its balance-tracking operations and other primitives, without any further assumptions on who and what assets ought to be involved in its transactions.

What’s new with V2?

At its core, Opium V2 uses a factory pattern to mint ERC20 tokens — representing SHORT and LONG positions- upon the creation of a derivative. Their creation is delegated to a factory contract that uses the create2 opcode to deterministically calculate the deployment address of a position based on their derivative hash as a salt.

The derivative hash acts as a unique identifier across the protocol that distinguishes each and every financial product deployed on top of Opium v2. It partially borrows inspiration from the design of the Bloomberg tickers and ISIN, where the uniqueness of their identifiers provides a guarantee that a trader is dealing with the desired product.

Gas Optimizations

As bytes manipulation — let alone string manipulation- can be unforgivably costly in Solidity, some niceties that have been implemented in the factory contract to optimize its gas consumption include the implementation of the EIP 1167 standard (Minimal Proxy Contract).

More customization for synthetic authors

Alongside its derivative hash, Opium v2 allows synthetic authors to assign a custom name to their derivative product. It is a purely cosmetic feature which, unlike the derivative hash, does not provide any guarantee of uniqueness and should not be relied upon for any critical business logic. However, should a derivative author create a series of financial products featuring many different synthetics, the possibility of customizing their positions’ names would improve their recognition in third-party derivative explorers.

More efficiency for arbitrageurs

Some of the other user-facing features featured in Opium v2 include the ability to redeem market neutral positions for their originally allocated collateral. The ability to be able to easily swap market neutral positions should make the user-experience of arbitrageurs and other market makers more smooth. Furthermore, they will be able to trade fractions of their positions — both market neutral and not.

Gasless permits for position holders

The EIP-2612 has been implemented in the Opium position ERC20 contracts to decrease the costs associated with changing allowances and transfers in secondary markets.

A more decentralized governance system and flexible oracle design

Lastly, a more granular governance system has been implemented that favors decentralization and ensures a single-responsibility separation of roles. Alongside that, Opium V2 now supports an even more flexible oracle design since, as of the new release, it does not enforce the synthetic oracles to comply with a specific interface.

About Opium

Opium Protocol is a universal and robust DeFi protocol that allows for creating, settling, and trading decentralised analogues of derivatives.

Explore Opium Protocol or try out Opium Finance

Stay informed and follow Opium.Team on Twitter.

Did you know that you can subscribe to our News Channel to get more exciting news delivered to your morning coffee?

Opium V2: your out-of-the-box derivative protocol was originally published in Opium on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Opium protocol is a universal protocol to create, settle and trade virtually all derivatives and financial instruments in a professional and trustless way. It allows anyone to build custom exchange-traded products on top of the EVM-Compatible blockchains. Once created, they can be traded freely via a network of relayers and will be priced according to supply and demand.

In our tutorial we will walk through the logic of a basic call option on ETH as an underlying.

If you are not familiar with the concept of call option, have a look at this introductory article.

You can find all the code in this tutorial on github. As our repository uses the hardhat’s forking feature to run our tests against the Opium Protocol’s Ethereum Mainnet contracts, we will need an Infura project ID — or any other node service provider of your choice, you name it. Set your Infura project id and mnemonic in a .env file with INFURA_API_KEY and MNEMONIC as the respective environment variables.

Next, let’s clone the repository and try to run the tests.

git clone git@github.com:RiccardoBiosas/opium-call-option-example.git
cd opium-call-option-example
yarn install
yarn test

Assuming everything has been set up correctly, all unit tests should pass with a green check mark. Congrats!

Code walk-through

At the core of each financial product built on top of the Opium Protocol there are two main components: the derivative recipe and the oracle recipe. The former is responsible for encoding the financial specifications of the product, whereas the latter is responsible for defining the data source that should be used to settle the product at expiry.

The structure of these two components need to adhere respectively to the IDerivativeLogic and IOracleId interfaces. In our example repository the contract implementing the IDerivativeLogic interface is OptionCallSyntheticIdMock and the contract implementing the IOracleId interface is the AdminOracleController.

However, the OptionController contract is where all the interactions with the Opium Protocol’s Core contract reside. The Opium Protocol’s Core contract is responsible for most of the financial logic processed by the Opium Protocol.

Before moving forward, bear in mind that all the code showcased here was written to illustrate the life-cycle of a basic option product on the Opium Protocol, so it goes without saying that it’s not meant to be run in a production environment!

Having said that, let’s start breaking down the OptionController chunk by chunk!

The OptionController inherits LibDerivative, a contract which defines the blueprint of a Derivative and getDerivativeHash — a function to return the footprint of an Opium’s financial product based on the hash of its packed parameters.

In the constructor, we pass the address of the Opium’s Registry contract. The Registry contract allows us to fetch and then store the addresses of all the Opium contracts that we need to implement our basic call option’s workflow. We’ve already introduced the Core contract, the other two contracts are the SyntheticAggregator and the TokenSpender. The SyntheticAggregator contract is responsible for caching and initializing a given financial product’s data, whereas the main responsibility of the TokenSpender contract is to manage the transfer of ERC20 tokens (i.e: at the moment of a derivative’s creation where an ERC20 token represents the product’s collateral or when a derivative is being settled and therefore the payout is being forwarded to the rightful party).

Then we set up our own derivative by calling the setDerivative function, which takes as an argument a LibDerivative.Derivative and stores it on the contract’s scope. Note that normally we wouldn’t need to do that, and that obviously in our example the owner could override the derivative variable in the middle of its life-cycle — but again, for the sake of breaking everything down step by step we will not concern ourselves with any practical design consideration.

Now that we’ve got our derivative, we are ready to mint its positions.

We call the create function. The OptionController’s create function is a wrapper around the Core’s create function. As an argument, it takes the _amount of derivatives (LONG/SHORT positions) that will be minted and the addresses of the buyer and the seller. Do note that in financial literature the buyer is associated with a LONG position and the seller is associated with a SHORT position.

The LONG/SHORT positions being minted are based upon the derivative that we have previously defined with the setDerivative function. In order for our create function call to be successful, the Core contract must be provided with the the appropriate margin. The required margin of our derivative is computed by the _computeMarginRequirement helper function, which adds up the long position’s and short position’s margins and multiplies them by the requested quantities.

And that’s it! We just minted our first positions.

Let’s now have a look at the callOptionWithDAICollateral tests.

opium-call-option-example/callOptionWithDAICollateral.ts at main · RiccardoBiosas/opium-call-option-example

First things first, here’s the derivative recipe of our ETH call option:

Here we specify the required margin, the maturity, the strike price, the address of the OracleId — our oracle recipe, the address of the token used as a margin and the address of the SyntheticId — our financial recipe.

In the tests workflow, the optionSeller account locks 400 DAI (derivative recipe’s margin * amount) in the Opium Protocol and receives an equal amount of LONG/SHORT ERC721O tokens. The seller is said to be market neutral until she exchanges her LONG positions with a buyer for 20 DAI.

Subsequently, now the seller holds only SHORT ERC721O tokens and the buyer holds only LONG ERC721O tokens.

The Opium Protocol supports European options. This means that any option created on top of the protocol can only be settled at expiry. As the expiry of our derivative is hardcoded to be 40 minutes in the future since its creation, in our tests we time-travel after the expiry so that our seller and buyer can exercise their positions.

Once again, for the sake of clarity we split the logic pertinent to the execution of the LONG/SHORT positions into two separate functions in the OptionController contract: respectively executeShort and executeLong.

Both functions are a wrapper around core.execute and they take the amount of positions to be exercised as an argument. Within their body, they calculate the hash of our derivative via LibDerivative.getDerivativeHash . Subsequently, they calculate the appropriate token id. For that purpose, we are using the LibPosition library which we attached to the bytes32 type. And now that we have computed on-chain all the necessary parameters, we can finally call core.execute !

Back to our callOptionWithDAICollateral tests, note that since both the seller and buyer accounts are interacting with the OpiumOptionController rather than directly interacting with the Opium Core contract, we need to enable the ‘third-party’ execution of the derivative by calling allowThirdParty. More generally, whenever the msg.sender is different from the EOA that holds a position, then calling allowThirdParty is necessary.

For a derivative to be settled, the data necessary to determine its outcome must be available (i.e: the current market price of the underlying against the strike price). In the Opium Protocol, the source of that data is the OracleAggregator. Normally — and ideally- the OracleAggregator would receive the required data from an on-chain oracle — such as Chainlink, UMA etc.-, but as the OracleAggregator was designed to be implementation-agnostic, in our example workflow we make use of AdminOracleController contract which receives off-chain data from its owner and then pushes it to the OracleAggregator. In our unit test we push a market price that is lower than the strike price, resulting in a favorable outcome for the seller of our ETH call option. The specifics of the payout of an Opium’s option are fully customizable and are defined in the getExecutionPayout of the contract implementing IDerivativeLogic.

In the case of our ETH call option, the seller received back the initial margin allocated to mint the LONG/SHORT positions. As the seller sold her LONG positions for 20 DAI, her profit amounts to 20 DAI. On the other hand, our buyer bought his LONG positions for 20 DAI, which corresponds to his net losses.

Vice versa, if the call option had expired in the money, the buyer’s payout would have amounted to the intrinsic value of the option unless the difference between the underlying’s market price and the strike price is greater than the allocated margin — in which case the buyer’s payout would be the entire option’s margin. As a result, the seller’s net loss would be 380DAI (margin * amount — paymentFromBuyer ) and the buyer would scoop up 380DAI as a profit!

Congrats, you built your first basic option call on top of the Opium Protocol!

Now that you got your feet wet, get in touch with the Opium community on the governance forum, the Opium DAO is eager to give grants to DeFi builders with interesting use-cases!

About Opium

Opium Protocol is a universal and robust DeFi protocol that allows for creating, settling, and trading decentralized derivatives.

Explore Opium Protocol or try out Opium Finance.

Stay informed and follow Opium.Team on Twitter.

Did you know that you can subscribe to our News Channel to get more exciting news delivered to your morning coffee?

Build a call option on Opium was originally published in Opium on Medium, where people are continuing the conversation by highlighting and responding to this story.

Blockchain trilemma

There’s much talk about decentralization, but in our opinion, the emphasis is often misplaced towards its technical side which tends to neglect the social side of the issue.

One of the acclaimed virtues of decentralized systems is that they achieve a democratizing effect through technological means.

The internet democratized access to information. DeFi has the potential to democratize access to finance. Once the domain of a few institutional players, now it’s open to retail investors. But if we are truly to succeed in such an endeavor, prohibitively high fees are an obstacle that ought to be overcome.

Computer science, however, is the art of trade-offs. There’s no such a thing as a free lunch, neither in finance nor in technology, which usually means that an improvement of a system component comes at the expense of another part of the same system.

Blockchain is no exception, as suggested by the blockchain trilemma — an assumption whereby the three main properties of a peer-to-peer system (security, decentralization and scalability) cannot be all improved at the same time.

Cryptoeconomics follows the same principle, which usually implies that blockchains with low fees tend to be more centralized than blockchains where fees are more significant. Thus, fees not only help guarantee decentralization and security from a technical perspective, but also bring centralization from a socioeconomic perspective. High transaction costs mean that fewer users can afford to make on-chain transactions and that they would pay only for high-value transactions. Does it imply that complex financial products will remain unaffordable for the masses?

We think we know the answer.

The constraints we mentioned so far apply to on-chain transactions. However, off-chain transactions are a totally different case, hence… welcome Polygon (former Matic) and the world of layer-2 solutions!

Scalability solutions

Layer-2 solutions are an active area of research and, as it stands now, it’s not a winner-take-all scenario. Currently, the most popular solutions are ZK-rollups, Optimistic roll-ups and different implementations of the Plasma model. There’s a broader spectrum of solutions that ranges from state channels to more exotic EVM-compatible sidechains, but they’ve not gained as much traction.

While the space is increasingly bullish on ZK scaling solutions and Optimism looms on the horizon, at the moment all eyes are set on Polygon. Polygon is a scalability solution that managed to improve some of the bottlenecks of plasma solutions, such as exit time withdrawal.

Generally speaking, the Plasma scalability model enables child-chains that are related to their main chain — in our case, the Ethereum mainnet — through a two-way peg whereby the child chains periodically commit a checkpoint to the root-chain. As the child chains can benefit from the security assumptions of their respective main chain, they can relax their own security assumptions in order to optimize the transaction throughput. There have been many discussions regarding some of the drawbacks of the Plasma design, from potential attack vectors due to the centralization of the validators to its data availability constraints. However, Polygon addressed most of the aforementioned concerns with its own architectural choices.

Aligned with the mission

Here at Opium our mission is to democratize and simplify access to complex financial products. In order to succeed in our undertaking, reaching a critical mass in terms of adoption is of paramount importance. Scalability, interoperability and low fees are all facets of the same challenge: large-scale user adoption. As the final launch of Ethereum 2.0 is an ever-sliding deadline, we are then looking forward to further collaboration with Polygon.

The reasoning underlying the integration of Polygon into the Opium ecosystem is the same as the rationale which led us to integrate PNetwork and launch Opium on Binance Smart Chain.

In fact, Polygon represents just the first, yet important, step of the Opium ecosystem’s layer-2 roadmap, as we plan to keep up with all the further developments in the space and both scalability and interoperability lie at the very core of our architectural and design choices.

Matic Network Now 'Polygon' as Platform Targets Ethereum's L2 Woes - CoinDesk

Tutorial: How to find new products on Polygon (Matic)

First, you need to switch the network to Polygon (Matic) on Opium.Finance. At the top of the screen, click on the Ethereum icon.

You will see the popup with other networks. Click on Polygon (Matic).

After you may be asked to switch the network in your wallet.

Now you are connected to Polygon (Matic) and can explore products there.

To access the Turbo products, click on the “TURBO” tab.

Congratulations! Now you are on the Turbo page.

Please read the article about Turbos before using them:

Introducing Opium TURBOS

Tutorial: How to transfer funds to Polygon (Matic)

1. The link to Matic Bridge V2–the page where you can transfer your assets from Ethereum to Polygon–is at the top of the screen when you are on the Polygon network. Click on the button and you will be redirected to the Polygon page.

Matic Bridge V2 https://wallet.matic.network/

First, connect your wallet.

Sign the transaction to log in.

Now you are on the main page. Click on the “Move funds to Matic Mainnet” button.

In this widget, you can swap your tokens from Ethereum to Matic. Choose the token and amount you want to transfer. Click on the transfer button.

Now confirm one transaction with a Final deposit.

Once the transaction is confirmed, it could take up to 10 minutes to receive the funds on Polygon.

Stay tuned

Opium Protocol is a universal and robust DeFi protocol that allows for creating, settling, and trading decentralized derivatives.

Explore Opium Protocol or try out Opium Finance.

Stay informed and follow Opium.Team on Twitter.

Did you know that you can subscribe to our News Channel to get more exciting news delivered to your morning coffee?

Opium Protocol is on Polygon (ex-Matic) was originally published in Opium on Medium, where people are continuing the conversation by highlighting and responding to this story.

Opium Network — open to anyone!

At Opium we are building an important piece of financial infrastructure for the future of finance. Opium Protocol is designed to be universal and robust so that it can be used by independent developers and organizations as well. But blockchains today are challenging to build on — especially when it comes to DeFi use-cases since it requires knowledge on finance and mathematics.

By using pre-existing derivative logic and oracle integrations on Opium Protocol, anyone can design and launch a decentralized derivative in a few hours! This SDK release marks yet another milestone in our continuous commitment to making it as easy as possible for independent organizations and developers to build on top of our work.

About the SDK

The use-cases for our new SDK range from building trading bots and market-making bots, to easy integrations with custom trading frontends.

As market-making and LPs are currently all the rage in the Ethereum landscape today, we expect our SDK to contribute to enriching the Opium ecosystem and also the overall DeFi derivatives space.

Our release includes

• JavaScript (TypeScript) SDK which includes utilities to make building on top of the Opium Exchange infrastructure easier
• Documentation Our SDK is written in Typescript from top to bottom, so do not hesitate to dig into the docs if you are in doubt whether you’re passing the correct type as an argument for some API request.
• HTTP API for authentication, interacting with the order book and system configuration
• Socket.io API for receiving real-time data on the orders, trades, and assets listed on Opium Exchange

Example code

Installing the SDK is as easy as installing your usual npm module:

npm i @opiumteam/oex-js

Have a look at the example code below to understand how it works.

Call to action: Start building!

In order for Opium Network to become a community-driven and community-governed ecosystem, we need builders to create bots, tools & derivatives using our universal and robust protocol.

Use our developer tooling such as the Opium Exchange SDK and API (links can be found earlier in the article), swap.rate SDK and API, and our developer documentation.

Also make sure to join the #developers channel in our Discord server for tech support — we’re online most of the time and are eager to help you get started!

About Opium

Opium is a universal and robust DeFi protocol that allows for creating, settling, and trading decentralised derivatives. Use our products today to speculate on opportunities inside and outside of DeFi, or hedge yourself against trading risks.

Explore Opium Protocol or try out Opium Exchange.

Stay informed through following us on Twitter, joining our Telegram chat and announcements channel.

Join the discussion on our Discord server!

Calling all developers: SDK for Opium Exchange available now! was originally published in Opium on Medium, where people are continuing the conversation by highlighting and responding to this story.

Unlike the other technological innovations from the past, however, its connection with regulations is much more nuanced and complex. Blockchain technology is, in fact, not only in an antithetical relationship with some specific regulatory systems, but it’s also, at the same time, a potential tool for the regulator and the corporate subjects of the regulations to keep track of the compliance process in a distributed tamper-proof ledger of records. The so called reg-tech (regulatory technology) market has been steadily growing in the last years as the asymmetry between the increasing difficulty of transnational regulations, the potential fines associated to them and the inefficiency of the current regulatory-compliance tools keeps getting wider. To be compliant with regulations is a huge financial burden for most companies and cost cutting in this exposes them to risk of fines from regulators. Blockchains can not only provide immutable auditable records, but also streamline a more decentralised corporate governance process that would prevent those in the corporate upper echelons from committing fraud.

Over the course of our current article, we’ll review the current blockchain landscape and its place within our current legislative system and what type of legal challenges the blockchain ecosystem will have to overcome.

In order for blockchains to be adopted in institutional settings, they face the dilemma of having to comply with two apparently contradictory sets of regulations.

The regulatory paradox

On the one hand, regulations such as KYC -know your customer- and AML — anti-money laundering- mandate digital systems to establish their users’ identities, which therefore entails the process of storing large amount of personal data for identification purposes. However, on the other hand, recently crafted regulatory frameworks such as GDPR require the same digital systems to make any personal data available to its owner and, more importantly, to be also able to amend and erase sensitive information if its respective user demands it.

The last requirement falls under article 17 of GDPR and it’s commonly referred to as the “right to be forgotten”. The compliance with such a requirement is proving to be especially tricky for blockchains, whose reputation and one of the main strengths lie in their tamper-proof immutability, whereas traditional CRUD databases can easily implement GDPR-compliant standards. However, simply pulling the plug on blockchain technology adoption and completely switching back to NoSQL and relational databases would be to betray the principles that were meant to inspire GDPR. In the era of big-tech where data is often branded as “the new oil”, users’ personal information is often at the epicenter of both tech-corporations’ predatory data-mining practice and also cyber-criminals that are after that same data. Especially in the last decade, cyber-crime organizations have become increasingly sophisticated and we’ve witnessed a rise in the frequency of data theft and data breaches — some of the readers might remember the many cyber-attacks that have been waged against the both healthcare and financial systems in the last few years, which have caused countless of personal data to be exposed to malicious third parties. Perhaps the most catastrophic of them has been the Equifax data breach, the monumental consumer credit reporting agency, where more than one hundred million people’s personal data was compromised.

GDPR and the rise of privacy-aware blockchain solutions

GDPR is meant to be the European response to restore data sovereignty and safeguard users’ privacy. Some legal experts have suggested that GDPR might be fundamentally incompatible with most of blockchain-related innovation — but also with AI and big data-related tech-. Nevertheless, the ethos guiding more privacy-aware regulations is well-intentioned insofar as there’s currently a technological and legislative gap when it comes to data protection and the GDPR is an effort towards the right goal. In fact, from a technological perspective, blockchain can also be regarded as a solution to data protection, but improvements are still needed from a privacy standpoint and GDPR has helped to highlight some of its current design flaws. In the light of these facts, going back to CRUD databases would expose the end-user to the same attack surface that has led to data loss and the numerous catastrophic data breaches that have taken place in the last years, where a server-side compromise of the databases is usually the most common vector of the hack.

We’ve previously mentioned the Equifax and the UK NHS as a case-study of data breaches. A growing number of governments and private entities are exploring blockchain-based solutions to make their financial sector more resilient towards data breaches. Some of these solutions leverage the combination of blockchain, off-chain layers and cryptographic techniques such as secure multiparty computation to both overcome the current scalability shortcomings of blockchain systems and to still make a meaningful use of personal data without violating the privacy of its users.

In Estonia, a blockchain technology has been implemented to the health-care system in order to safely manage time-stamped records of patients’ data and more solutions are being explored in the digital identity sector.

Deploying a blockchain solution for the management of healthcare and financial records can improve the data availability and resiliency towards a large attack surface that ranges from ransomwares to DDoS attacks. As a data provider would become a node on a blockchain network, a network or hardware failure wouldn’t entail data loss or even a downtime in the data availability due to the higher tolerance of blockchain’s decentralized architecture. For a similar reason, it would also make DDoS attacks an ineffective attack vector as targeting a specific node on the network wouldn’t affect the overall availability and integrity of the data. And as the second-layer solutions will improve, the management of the data on a node could be reduced to just securing the cryptographic properties of the system in order to access the actual patients’ records on the network without forcing the user to either give up control of his data or overly disclosing personal information to third-parties.

Blockchains: a leap forward in security and a step back in privacy?

The regulatory and privacy conundrum has made the divide between public and private blockchains even wider. Currently, private and consortium blockchains are ahead of the game, as they’ve been designed to be as institutionally-friendly and regulatory-compliant as possible at the expense of a fully decentralized approach.

In particular, the Hyperledger projects — and specifically Hyperledger fabric- have been making relevant progress when it comes to GDPR-compliance and privacy. Hyperledger fabric’s architecture implements a granular control of data accessibility both at the chaincode-level and network-level (through channels). In fact, until recently, the only way to enforce confidentiality was by creating new channels where only the authorized transacting parties would have access to some specific data. As a network grows, however, the overhead that is associated with the creation of a new channel -which includes managing new policies, refactoring the membership service provider and possibly the chaincodes- would make such an approach rather inefficient. As a solution to such a problem, private data collections have been introduced.

Private data collections in hyperledger

A private data collection is a collection of data whose hash is stored on the blockchain ledger, whereas the data itself is stored either on some form off-chain storage or sideDB (side-databases). The private data itself will then only be accessible to the authorized parties and will be distributed via a peer-to-peer protocol. At the same time, the hash of that data will be stored on the public ledger and will be accessible to everyone so that it represents an evidence of the transaction. Such an approach allows to granularly differentiate between sensitive data and data that can be public, without giving up on a peer-to-peer and partially decentralized architecture and overly increasing the network overhead.

Public blockchains and regulatory compliance

As for public blockchains, it’s reasonable to assume that the current state of most of the projects is most likely not GDPR-compliant. However, the extent to which it’s not GDPR-compliant is still unclear, as there are many grey areas that need to be clarified by the related jurisprudence.

One of the most contentious points is whether the hashed data still qualifies as personal data under the GDPR. Blockchains are based on asymmetric encryption, whereby a public key is freely shared with third-parties which will then use it to encrypt messages in a secure way. Subsequently, the owner of the public key will use the respective private key to decrypt the aforementioned messages. On blockchains such as bitcoin and ethereum, a user’s address and identity on the ledger is represented by a hash of their public key. The networks that follow this approach are defined as pseudonymous. Their transactions history is fully transparent and each party on the network is linked to a public key which can eventually be traced back to an IP address and the person associated with that IP address.

According to GDPR, all the data that can make a person identifiable on a network through the deployment of means that are likely to be used still falls under the notion of personal data. As blockchain analytical tools become more efficient and widely used, this could eventually expose many blockchain platforms to legal liabilities.

On the other end of the spectrum, there are public blockchains that follow a privacy-by-design approach. In the case of Monero, for instance, a cryptographic technique called ring signatures is implemented to mix together groups of transactions in such a way that a specific transaction cannot then be traced back to a specific public key. This approach is likely to be GDPR-compliant insofar as public keys don’t make a subject identifiable on the network, but at the same time makes the process of meeting the requirements of KYC and AML regulations extremely challenging.

So are public blockchains bound to fall short of overcoming the regulatory paradox?

Zero-knowledge proofs

A growing amount of interest has been generated by zero-knowledge proofs as they promise to enhance on-chain privacy in a regulatory-compliant fashion. Zero-knowledge proofs are an advanced, and still mostly experimental, cryptographic technique where one party can uncontroversially prove the truthfulness of a statement without providing any additional information to back up their knowledge regarding that statement. They could be used to mathematically prove that a party satisfies the requirements mandated by KYC and AML regulations without disclosing any personal data that would expose the transaction to GDPR liabilities.

A working implementation of a zero-knowledge proof-based architecture has been achieved by the Zcash blockchain. As more proof-of-concepts of this cryptographic technique transition from the ivory tower of academia to real world use-cases, we can expect them to be more widely adopted in the public blockchain ecosystem.

In our current article, we placed the emphasis on the regulatory frameworks that concern data protection in the digital world. As in BrikkApp we’re building a hyperledger-powered real estate investments marketplace, the focus of our next chapter in the “Blockchain and Regulations” series will be on the specific regulatory challenges at the intersection of blockchain, the real estate market and online investments and how we’re addressing them. Lastly, we’ll delve into how regulations are evolving to keep up with the innovative fundraising, asset tokenization and crowdfunding enabled by blockchain technology. As we’re also starting another article series on consensus protocols in the blockchain ecosystem, follow our BrikkApp medium account to be kept up-to-date!

Blockchains and the evolution of regulations was originally published in BrikkApp on Medium, where people are continuing the conversation by highlighting and responding to this story.

The two main representatives to the categories of turing-complete public blockchains and turing-complete private and consortium blockchains that have stirred the most interest are ethereum and the hyperledger project.

Ethereum

Ethereum was first devised in the late 2013, and it was the first public blockchain to generalize its core protocol beyond the scope of cryptocurrency issuance. Unlike bitcoin, ethereum’s built-in currency, ether, is not primarily designed to be a digital currency for a new worldwide payment system, but as an internal commodity that fuels its DApp ecosystem.

DApps are decentralized applications, and in ethereum every DApp transaction is paid in ether. The main rationale behind this choice lies in the public nature of its network. Ethereum is pseudonymous and open to everyone, which exposes it to a huge attack surface. An anonymous malicious actor could clog the ethereum blockchain by sending numerous requests to the DApps on top of it or to do some other form of computation. Such a spam threat is prevented by making it so every computation that is performed on the network costs money. This would eventually result in our attacker desisting from broadcasting spam transactions because it would become too expensive on the long term.

As clever as this architectural choice is, this has not averted non-malicious network congestions in many instances due to ethereum’s currently limited transaction throughput. This bottleneck is forecasted to be addressed in the future, when new scalability solutions (both on-chain and through side-chains) will be implemented. Sharding, plasma and other sidechains are some of the proposed scaling solutions that are currently under heavy development. They’re, however, not a panacea, since they might pose either security or centralization risks to ethereum, and they’re far from being a well-tested technology.

Scalability won’t be the only focus of ethereum’s future upgrades. The protocol underlying both its economic incentives model and consensus mechanism will soon be revolutionized as well.

Ethereum currently implements a flavor of proof-of-work, but it will eventually switch to proof-of-stake in the future in order to be more energy-efficient.

In general, in proof-of-work the pool of validators, also called miners, is required to perform complex computations in a race to be the first to solve a cryptographic puzzle. The reward for winning such a computational race is monetary and ensures that the validators are provided with an economic incentive to participate in the consensus mechanism, which safeguards the consistency of the network. Proof-of-work, however, has proven to be extremely wasteful in terms of energy consumption.

In proof-of-stake the validators, usually called forgers, are also rewarded, but, rather than solving computationally demanding puzzles, they stake part of their tokens as a requirement to participate in the consensus protocol. The likelihood to be the recipient of a monetary reward is roughly proportional to how much tokens have been deposited in the stake.

An in-depth review of all the various flavors of consensus mechanisms is beyond the scope of our current article. Follow our account to be notified when we’ll proceed delving further into the nitty-gritty of consensus protocols, cryptoeconomics and mechanism design.

Hyperledger projects

The hyperledger project originated when the concept of blockchain started gaining traction among private tech-corporations. It’s not a single blockchain, but an umbrella of projects hosted by the linux foundation in partnership with different companies, which provide modular blockchain architectures and tools tailored for the specific needs of enterprise use-cases. In fact, the hyperledger projects are divided in frameworks, which are the actual blockchain platforms, and tools, which are instruments that aim to streamline the development process of the chosen hyperledger framework.

In our current article we’ll give a general introduction to the features of the hyperledger project and how it differs from ethereum and other public blockchains. Among the various hyperledger frameworks, the most mature from a development viewpoint is hyperledger fabric, which is one of the reasons why it’s the platform of choice here at BrikkApp.

In the future, we will endeavor in a much more in-depth analysis of fabric’s design and peculiarities and how it distinguishes itself from other hyperledger platforms such as sawtooth, indy and burrow.

The hyperledger ecosystem

Each hyperledger’s tool has a different purpose that varies from implementing different deployment models, facilitating the execution of smart contracts and benchmarking the performance of the network to adding new features such as interoperability with other blockchain frameworks.

The modularity ethos that characterizes the hyperledger project is extended even further: the hyperledger blockchain frameworks are usually partitioned into relatively independent components that can be replaced with alternative modules which serve the same purpose.

Consensus protocols in hyperledger

The chosen framework’s consensus protocol is one of the main customizable components. Each enterprise grade blockchain use-case comes with different trust relationships between its specific participants: the pluggable consensus approach is designed exactly to address the nuances of the spectrum of trust in the most tailored way possible. It’s therefore possible to implement both consensus protocols that are similar in nature to public-blockchains, also called pBFT — practical byzantine fault tolerance-, or quasi-centralized.

Practical byzantine fault-tolerance is designed to survive byzantine failures, but it doesn’t require economic incentives since all the identities of the network’s actors are known.

Byzantine failures are a particular class of failures in a distributed system, where a single node is an unreliable source of truth on the state of the network and may act in the pursuit of its own self-interest at the expense of the overall network’s consistency. On the other end of the spectrum of failure modes, we have non-malicious failures, where a failure is not caused by the intentional behavior of a node, but due to causes such as hardware crashes and network latency.

Quasi-centralized consensus is less secure and it’s mostly resilient against non-malicious failures. It is, however, much more efficient and provides better performance. In a quasi-centralized consensus a single entity, or a very restricted pool of actors, is responsible for ordering and broadcasting transactions whose validity is cryptographically checked by other nodes in the network — also called endorsers.

Channels in the network

Furthermore, the defined consensus protocol is not as overarching as in ethereum: hyperledger’s networks are further segmented into channels. A channel can be regarded as a partition of the network which is governed by a different rule-set defined by two other fundamental customizable components: the identity service and the policy service. The identity service not only defines the roles played by the various actors in the networks — whether they are validators, endorsers or peers-, but also establishes the memberships to the specific sub-channels. On the other hand, the rule-set that characterizes the aforementioned channels is defined in the blockchain framework’s policy service. One of the use-cases of the identity service and policy service modules is, for instance, the enforcement of private transactions among a subset of network participants.

The combination between all the different flavor of blockchain frameworks and the vast array of tools empower developers to create customized tech-stacks able to meet the most specific requirements of enterprise solutions.

The key differences between the hyperledger projects and ethereum

Over the course of the last few years, the word blockchain has been indelibly linked with the idea of cryptocurrency by an often lazy press coverage. As much as it is true that cryptocurrency issuance is just one of the numerous applications of blockchain as underlying technology stack, in the case of public blockchains the two concepts are deeply intertwined. As we’ve concluded in the ethereum chapter, public blockchains need economic incentives to ensure the security of their networks. Especially in turing-complete public blockchains, attackers can spam the network with never-ending loop-based computational requests that would halt the flow of transactions. These attacks are a form of the more commonly known DoS — denial of service. Economic incentives aren’t meant solely to make DoS financially infeasible , but also to incentivize desired behaviors in the users of the network, such as, in the case of proof-of-work blockchains, participating in the block generation process as honest miners. So, in a public blockchain, a digital currency is not only its main value proposition, but a vital component of its network governance and security as well.

In private blockchains, the security concerns are such that cryptoeconomic incentives are not as fundamental, if not superfluous.

On-chain assets

Therefore, the first noteworthy difference from ethereum is that the hyperledger project has decoupled the notion of distributed ledger from the asset that is built on top of it. Such a currency-agnostic approach allows to perform transactions within the network with no fees and more freedom to model any type of asset on top of the network.

Transaction confidentiality

Furthermore, as we’ve mentioned previously, hyperledger’s transactions can be confidential, whereas ethereum’s global state, which keeps track of the mapping between all its network’s addresses and respective account balances, is ubiquitously public. While a fully transparent transactions history enables everyone to verify the consistency of its log history and makes possible a trustless financial ecosystem, it doesn’t always sit well with regulatory frameworks and the specific transactional needs of consortiums of corporations. Hyperledger’s capability to compartmentalize the transaction flow into channels with ad-hoc policies and restricted membership allows a more fine-grained control over the underlying consensus protocol and it’s one of the pivotal features that makes it compliant with regulations such as GDPR.

Scalability

The channelization of the transaction flow makes it so not all nodes need to achieve consensus on the order of a transaction at the same time, but at first only that specific transaction’s involved parties will be required to reach an agreement. This segmentation of a hyperledger framework’s is paired with a permissioned mode of participation to the consensus process where nodes play different roles in the transaction life cycle and maintenance of network consistency. The specificities with which nodes partake in the consensus protocol depend also on the selected hyperledger framework. For instance, in hyperledger fabric these roles are divided in orderers, endorsers and peers. Peers are the recipients of ordered sets of transactions, which they then commit to the network. Endorsers check the cryptographic signatures of a transaction to verify that is consistent with the state of the ledger. Finally, orderers ensure that the same logical order is broadcasted to the peers. Such a permissioned and modular approach benefits the overall scalability of the network, which is the upper bound of transactions that can be processed in a given time-frame. This is different from ethereum, where the roles played by the nodes that partake in the consensus protocol are identical, at the expense of its transaction throughput.

Smart contracts and chaincode

At the beginning of the article, we’ve stated that both ethereum and hyperledger frameworks are turing complete. In hyperledger, smart contracts are called chaincode and, unlike ethereum’s smart contracts, don’t require fees to be executed. Chaincodes are developed with existing programming languages, whereas in ethereum smart contracts are developed with newly designed domain-specific languages such as solidity and vyper. In the case of hyperledger fabric, the most well-supported language for the development of chaincode is golang. The execution of smart contracts in ethereum is always processed by the ethereum virtual machine, a stack-based runtime environment that executes all the programs broadcasted in the network. Notably, in the hyperledger ecosystem, the framework hyperledger burrow provides a permissioned version of the ethereum virtual machine as one of its main components, so that interoperability with ethereum’s smart contracts is made possible. As for the rest of the hyperledger projects, the instantiation and deployment of chaincode depend on the specific components of that framework’s architectures, and they can be streamlined with hyperledger tools such as hyperledger composer and hyperledger transact.

Conclusion

In summary, ethereum appears to be the dominant platform for general-purpose applications that are meant to be deployed and used in public pseudonymous networks and, at the moment, can tolerate a relatively low transaction throughput. In the struggle for enterprise adoption, however, hyperledger is the clear winner, thanks to the flexibility and high-performance provided by its modular design philosophy which can satisfy the most nuanced application-specific requirements.

Nevertheless, what we can most likely expect from the future is that the distributed ledger landscape won’t be dominated by a single hegemonic platform, but it will be a rich and diversified ecosystem of different coexisting technology stacks. In this ecosystem, both hyperledger and ethereum are poised to be key players for distinct use-cases.

One of those use-cases will be innovating and democratizing the real estate market. At BrikkApp we’ve decided to leverage the hyperledger technology to boost the transparency of the property investment market and tokenize real estate assets. Follow our medium account to be kept up-to-date on our future platform developments and to read more technical insights on the blockchain ecosystem.

A comparative analysis of Ethereum and Hyperledger: the road to mainstream adoption was originally published in BrikkApp on Medium, where people are continuing the conversation by highlighting and responding to this story.

In fact, blockchains are themselves a subclass of the larger distributed system category defined as distributed ledger technology.

The bare-bones anatomy of a blockchain is, essentially, a data structure known as linked list, but with few crucial tweaks that ensure immutability and decentralization.

A linked list is a linear collection of elements where each element points to the next. The linkage between its elements is achieved through a data type named pointer, which is a reference to the memory location of an object.

What is a blockchain?

A blockchain is a backward linked list whose elements can be viewed as blocks. Each one of its blocks references to its previous block through a hash pointer up to the genesis block, which is the first block in the collection of elements that constitutes the blockchain.

A hash is the output of a cryptographic hash function, which is a function that takes inputs of any size and returns a fixed-length output. Such a function has three pivotal properties: it is deterministic — the same input will always produce the same output-, it’s pre-image resistant — the returned output doesn’t reveal any information about the input- and, lastly, it’s collision-resistant — two different inputs are extremely unlikely to return the same output-.

An understanding of these cryptographic properties is not just a marginal technicality, but it’s of essence to have a solid grasp of how the ingenious blockchain design has the potential to revolutionize entire industries across the financial landscape in a world that is becoming more data-driven by the day.

It’s the concoction between the structure of a linked list and cryptography that conjures up one of blockchain’s fundamental properties: immutability.

Since each block’s hash is computed from its own data and each block’s data contains a hash of the data of the previous block, if a malicious actor were to try to alter the data contained in one of the blocks this would alter the entire chain of hashes. One of the hash function’s properties makes it so that even the smallest change in the function’s input will deterministically return a completely different output. In our example, the attacker, after altering the data inside of the target block and its current block hash, would have to subsequently re-calculate the hashes of all the successive elements from the target block onward. Since the process of generating a valid hash that meets the specific blockchain protocol’s criteria is highly computationally-expensive, recreating a consistent chain of blocks is prohibitive for even the most crafty attackers. The criteria that define the difficulty of computing a block hash strictly depend on the specific consensus protocol of a blockchain implementation and can vary quite widely: public blockchains, which are open networks of anonymous or pseudonymous actors, have more computationally-demanding criteria which, paired with economic incentives, make them designed to enforce immutability even against the most well-funded threat models. On the other hand, private and consortium blockchains, which are comprised of restricted networks with identifiable users, have less challenging block generation criteria, since they’re required to face a less menacing spectrum of threat models.

Despite their implementations’ differences, all blockchains are in essence the same data structure: a timestamped peer-to-peer cryptographic fingerprints-based backward linked list which is a ledger of records. Unlike traditional linked lists, where it’s possible to delete elements, a blockchain is an append-only data structure which makes it both tamper-proof and immutable.

Blockchains and distributed ledgers

The technical underpinnings of the data structure at the core of the blockchain are also what defines it as a very specific type of distributed ledger. Distributed ledgers share the same core characteristics as blockchain’s — immutability, censorship-resistance, full auditability and decentralized storage- but can differ significantly in their data structure implementations. Other data structures that are used to model implementations of different types of distributed ledgers include trees and graphs.

Public, consortium and private blockchains: degrees of decentralization

Within the blockchain ecosystem, one of the main benchmarks to distinguish between different types of blockchains and lay down a taxonomy is its degree of decentralization.

Their implementations can be subdivided in public and private and each one of these compartmentalizations can be either permissionless or permissioned. This allows to build architectures whose level of decentralization is not binary, but lies on a spectrum between distributed and fully decentralized.

The public and private notions refer to the openness of the network, while the concepts of permissionless and permissioned refer to the level of user-privilege. The modular mixture of these features, specifically public on the network-side and permissioned from a user-privilege perspective, defines the category of consortium blockchains.

Public blockchains

In public blockchains, which are mostly known for the cryptocurrency market, anyone can join, read the network and perform transactions. We’ve previously mentioned the hash function-based block generation process: such a process is commonly known as consensus protocol. Permissionless blockchains allow anyone who meet the criteria defined in the consensus protocol to join the pool of validators, which is the set of users who append new blocks of data to the blockchain and update its global state. Public permissionless blockchains are the most decentralized implementation and, as such and also due to their mostly anonymous nature, are exposed to the largest attack surface. In order to be resilient against it, their consensus protocol is paired with a sybil-prevention mechanism through a set of economic incentives to promote honest behaviour — the sybil attack is a malicious way of overtaking distributed networks by forging a large number of fake identities.

Consortium blockchains

This overhead in the consensus protocol makes public permissionless systems quite slow since it decreases its transaction throughput, which is the rate with which new blocks are appended to the chain. More generally, there’s a trade-off between decentralization and scalability.

However, not all public blockchains are permissionless: some of them only allow a pre-selected pool of participants to either partially or entirely control the consensus process. This increases the scalability of the blockchain framework at the expense of the decentralization of its network. These systems are defined as permissioned, and public permissioned blockchains are also called consortium blockchains.

Private blockchains

On the other end of the decentralization spectrum, we now have private blockchains. These too can be either permissionless or permissioned, albeit the latter is more common. Their networks cannot be joined without permission and, depending on the implementation, their state cannot be read by non-participants. Their architecture is more modular and designed with a more granular permission system than public blockchains. Also, at the expense of decentralization, they achieve greater scalability and privacy. All these features make it so that they’re more customizable to enterprise-specific requirements and regulatory frameworks.

In fact, as mentioned in our previous article, this approach has turned out so far to be the favorite for public institutions and corporations. In general, closed reputation systems where the identities of the participants are known necessitate a less strict incentive structure than anonymous networks. Nevertheless they still require cryptographic auditability of their data and check and balances among their competing parties, which is where private blockchains come into play.

Blockchains as decentralized computers: turing-completeness

The second distinctive feature to categorize blockchains is turing-completeness. As we will see, turing-completeness is also a fundamental property of the programming language that they support to develop applications on top of them.

If, on the one hand, a blockchain can be regarded as a tamper-proof record-keeping technology, on the other hand it’s also a world computer whose computations are run by many nodes across the globe. These computations are performed in a decentralized fashion through the scripting language supported by the specific blockchain implementation. Turing-completeness is, in a way, a measure of the computational capabilities and expressiveness of that given language. An expressive programming language is able to represent through its syntax constructs a wide compass of ideas and concepts. When a language is turing-complete, it supports iterative constructs — such as for loops- that further broaden the range of computations it can represent.

Turing-complete blockchains enable the development of smart contracts — programs that run on a distributed ledger- that are expressive enough to replicate complex financial functions, allowing the creation of a whole new economic ecosystem on top of them.

Here at BrikkApp we’re working both on a web-based online property investment aggregator to bolster the transparency of the real estate market and empower investors to make more informed decisions, and on a planned blockchain integration to tokenise real estate property investments.

In the next article we will delve more into public and private blockchains with a comparison between ethereum and the hyperledger project. Follow our medium account to keep up to date with the next publications!

An introduction to the blockchain ecosystem and its taxonomy was originally published in BrikkApp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Commercial real estate is one of the key legacy sectors that is the most burdened with expensive middlemen, information asymmetry, bureaucratic hurdles and lack of auditable data and overall transparency.

All these factors, paired with high capital barriers of entry, have defined the real estate market as a speculative investment for the few and a highly stressful once-in-a-lifetime investment for the many.

As a matter of fact, the real estate sector, despite it being the world’s most valuable asset class with an evaluation that is around $200 trillion, is also a notoriously illiquid market. Housing market’s higher price point and compliance costs have historically hindered small investors from adding it to their balance sheet as a speculative investment.

This lack of flexibility won’t stand the test of time as new generational trends are set to shape the market. From millennials to generation Z, the future investors are digital native demographics whose consumer behaviour is deeply intertwined with internet mechanics.

As it is now, real estate is mostly a slow offline business: from a buyer’s perspective, it requires months to gather an adequate knowledge of the local market and from a seller’s viewpoint, the lack of market liquidity can prolong the transaction for months, if not years.

Blockchain technology provides a solution to both the information bottleneck and the financial bottleneck.

Single source of truth

Unlike the stock market, real estate assets are a non-fungible commodity which causes the market where they’re traded to be afflicted with information asymmetries. This means that the market is structured in such a way that one party, in this case the seller, possesses a greater wealth of knowledge than the other party, the buyer.

In fact, potential investors have to familiarize themselves with the specificities of the neighborhood and, eventually, rely on the more accurate knowledge of an intermediary who has also monitored past transactions in the local market. Blockchain is designed to be a tamper-proof record-keeping technology: it enables financial and social ecosystems with mutually distrusting agents or conflictual information to rely on an auditable and publicly accessible single source of truth, therefore boosting the transparency and enforcing an efficient dispute resolution mechanism. Albeit still in the early stages, this use-case has already been tested by state actors to implement nation-wide land registries and more countries are planning to join. Coupled with crowdsourced information and data aggregators, the capability of blockchain to produce immutable records empowers the end-consumer by reducing the gap of information between the seller and the buyer and disintermediating the latter from relying on third-parties, and it proves to be especially useful for markets that are not perfect information systems such as the real estate.

The above diagram is an example of a smart contract-based application to perform transactions of tokenized real estate properties on a blockchain network (specifically, ethereum).

Tokenization and fractional ownership

The local and non-fungible nature of properties as an asset class leads to an inefficient price discovery mechanism which has a detrimental effect on liquidity.

The function of blockchain as an immutable ledger of records makes the financial ecosystem more open and a level-playing field between buyer and seller, but there’s more to blockchain than being a record-management tool.

Another feature has the potential to stimulate liquidity and empower a much greater pool of investors who lack of significant amount of capital: tokenization.

Fractional ownership through tokenization allows to encode tokens, units of digital information that are meant to represent and keep track of the ownership of real-world assets, into a set of rules with smart contracts that are deployed on the blockchain network. In this particular case, a token is a measure of the percentage ownership in a property. The allocation of the tokens and the lower bound of this percentage can be as low as encoded in the rules of the smart contract, therefore granting more freedom to the seller. This will in turn lower the capital barriers to have a stake in the housing market since, rather than an entire property, it will facilitate the acquisition of just a fraction of it to a global pool of investors. At the same time, this approach also offers full transparency as the rules of the contract reside on the blockchain and are immutable. The housing market will hence be democratized as both a speculative and long-term asset.

Thus, the conundrum is not whether a blockchain-type of technology might have a use-case in the real estate sector, but, specifically, which flavour of blockchain is the most suitable. Whereas public blockchains, such as bitcoin and ethereum, are designed with a more adversarial approach in mind, as their users are either anonymous or pseudonymous, consortium and private blockchains, such as the hyperledger project, are designed for mutually distrusting competing actors who are nevertheless identifiable, hence the lesser degree of decentralization. This allows consortium and private blockchains to be more easily regulatory-compliant.

From KYC/AML to privacy-oriented legal frameworks such as GDPR, private and consortium blockchains are architected to be more institutionally-friendly.

Moreover, their more centralized nature still makes them more flexible than a relational database. Similarly to public blockchains, consortium and private blockchains have their own consensus protocol, but more modular and customizable according to the requirements of their use-case. This allows to embed a set of policies in their network to regulate the business logic among their actors and enforce immutability for record-keeping purposes.

Lastly, in a financial landscape that will be dominated by demographic cohorts that have been influenced by new economic paradigms, from the attention economy to the sharing economy, traditional industries are poised to face substantial transformation. The new generations are digital natives, demand more flexibility and data transparency and the trend of digitization of offline sectors is bound to expedite with the internet of things. Blockchain is one of the tools with which the fintech and real estate market can adapt to these structural changes.

In our next articles we will bring you more information about the comparison between consortium and public blockchains, and the rationale behind why here at BrikkApp we’ve decided to adopt such a technology to increase the transparency of the property investment market will be further detailed. Follow us and keep in touch!

Blockchain and the democratization of real estate investing was originally published in BrikkApp on Medium, where people are continuing the conversation by highlighting and responding to this story.