Ever since the Equilibrium team has come up with the Unified Ledger App proposition for the Ecosystem, the proposal itself has received a lot of attention and positive feedback both from within and from outside of the ecosystem. It continues gaining traction after we came up with the actual referenda which you can find and support here.

The aim of this post is to re-iterate the main ideas and advantages behind the proposal, pinpoint why it is of great benefit to the parachain projects, and encourage an open discussion about the future prospects of the app that should ultimately serve all of the ecosystem at acceptable costs.

Motivation

There should be one universal Ledger app that will work with all parachains. We see the following problems of creating separate Ledger apps for different parachains:

1. The Ledger team is overwhelmed with work and explicitly asks to curb the number of apps they need to support from the ecosystem, as well as limit the frequency of the app updates, making them no more than once per quarter.
2. Unique derivation path for each app (a unique account for each relay chain and parachain). Which leads to a number of problems:

• The inability to participate in a crowdloan with a Ledger with guaranteed access to its rewards on a parachain without exporting mnemonics to less secure environments (for example, an extension, a mobile application). Most likely, a new project that participates in the crowdloan will not have its app built for a long time, because of which users will have to wait and get a negative experience from the entire ecosystem.
• Most applications do not have derivation path selection functionality. So users, who transfer tokens from Kusama to Kusama-based parachain, for example, have their account changed and lose access to their tokens. The entire flow is not directly obvious to the average user (need to export mnemonic with correct derivation path).
• Even if developers of parachain/relay chain applications will include functionality for selecting derivation paths in their Ledger applications, this will cause all applications to need to upgrade to support new parachains when they emerge. The alternative is for users to set the derivation path manually, which is complicated for the average user and doesn’t simplify the already cumbersome Polkadot user experience.

3. The Ledger app works as a full-scale decoder, where pallet numbers and their respective methods are hard-coded. This leads to the following problems:

• Some transactions become unavailable after the runtime upgrade if there are changes to pallet indices and/or changes to extrinsic types.
• These problems in conjunction with slow Ledger support response lead to the fact that users lose access to their assets for a prolonged period of time

Proposed solution

Abandon call data decoding on the device (similar to EVM-compatible apps).

The main reason for the necessity to make a distinct Ledger app for each parachain is the need to decode the call data of every extrinsic.

Ethereum Ledger app, for example, never decodes transactions, one exception being an ERC-20 transfer. That is, the user checks data in the metamask wallet, for example, and approves it on a Ledger.

There are several differences with substrate parachains compared to standard smart contract chains, and it’s not just frequent upgrades:

1. Large transactions that are difficult to validate, even on a large screen.
2. Frequent runtime upgrades.
3. Transactions that are difficult/impossible for the average user to understand, such as XCM or ORML (excellent developments but designed to be as general as possible for various projects to use).

However, there is a major advantage to the substrate technology — we can change and adapt it to make it more user-friendly. We have a long-term vision of achieving this, but in the meantime, we want to help our clients and clients of other parachains access their assets as quickly as possible.

Our solution solves all three of the above problems. For now, this solution works only for balance pallets, but it supports all types of balances and effectively covers the majority of on-chain transactions in Polkadot. Also, we’re not just adding metadata for each parachain; we’re transforming the transaction into human-readable text for each parachain (sometimes different approaches are needed for the same pallet).

Security of the proposed solution

We’ve seen quite a lot of debates on the security of our approach. Most of our opponents refer to insecure blind signing. But it has become an industry standard for EVM (maybe unfortunately, but it’s the fact). Furthermore, as said above, the most common transactions (asset transfers) will be subject to clear sign and the scope of clear signed transactions will be expanding as new app developments kick in. Also, we’ve been in constant communication with the Ledger team to ensure our solution complies with their security standards.

Let’s summarize why the proposed solution actually secure:

1. As mentioned earlier, we built the application based on EVM, and our security complies with widely spread EVM standards.
2. The application’s architecture will allow the future addition of processing new commonly used transaction types, such as governance or staking.
3. The hash verification process is not ultimately secure in the same way the verification of large and complex transactions is (more on that below in the concerns section). We have a clear vision of how to modify our approach in striving to make the app more secure and user-friendly (details on this are below as well)

Lastly, the idea for this application was not born out of a desire to obtain a piece of the treasury but out of the necessity of having this application for our parachain and other parachains in our ecosystem. This is evident from the numerous comments and feedback we received while pursuing the common app goal.

Exact Implementation

It is very important to re-iterate that the exact implementation of the proposed app will work identically to the way Ledger apps work in Ethereum:

1. Most common transactions such as Balance (and other asset operations) will be supported in the clear sign mode. See this spreadsheet for the breakdown of the different asset modules we’re planning to support.
2. Blind sign mode is something that the user has to turn on manually on the device before he will have the ability to use it.
3. Display the hash of the call data both in the extension/mobile application and on the Ledger device.

Communication with the Ledger Team

Having said that, we’ve been in constant contact with the Ledger team on the subject, and here’s the recap of the latest call and the questions that have been discussed:

1. Problem with multiple derivation paths: The proposed app will automatically select the needed derivation path between Polkadot and Kusama relay chains, depending on where the supported parachain is.
2. Users should not blindly sign by default: The app will work the same way as EVM-based apps: users will have to manually turn on the hash signing option on the device themselves.
3. Frequent app updates are time-consuming and not optimal, how can we avoid that? This is what we as an ecosystem need to sort out, from our end, we proposed to make updates no more frequent than once per quarter.
4. If we manage app updates once per quarter, can we guarantee a clear sign when the app is not updated? No, we can’t, so those parachains who have implemented some breaking changes won’t work in the clear sign mode but still will have a blind sign functionality available. Yet these updates are quite seldom in our experience and we will monitor the main modules/pallets for the updates.
5. It’s up to the ecosystem to decide on how to move forward with the app and what other common transactions to support for the clear sign mode: Indeed, this is the reason we’ve created a telegram group with multiple parachain representatives and have been vocal about our propositions during parachain round table calls and in discussions with Parity.

Addressing objections and concerns

We’ve received numerous Polkassembly comments and posts related to the proposed solution and would love to address them all here in one place. We invite the Zondax team, Parity, and Ledger representatives to comment.

1. Security concern: Probably the most significant one we’ve received, which can be formulated like this:

Q: How do you verify that what you are signing is actually what the hot wallet shows you? This is impossible and therefore totally insecure.

A: The concerns associated with signing hashes are usually explained using the example of simple transactions, but let’s look at the example of an XCM transaction, which is the main feature of Polkadot parachains.

• The size of the transaction — it is almost impossible to validate it on the Ledger device, moreover the device itself frequently freezes when presented with a transaction of such size
• Arguments and methods that are incomprehensible to the user
• Recipient address in public key format => You need to use third-party applications for validation
• The transaction may appear in the encoded format of the recipient’s chain => you need to use third-party applications for validation

To check such a transaction user must use 3rd party instruments to validate it, raising all the same security concerns as with the hash signing. Hard to imagine any person in his right mind doing this.

We already talked about possible future approaches to the issue of clear/blind signing we would like to discuss more with the community and Parity:

The first approach is to change the SignedPayload struct to create a human-readable string from extrinsic, so the users will sign a string, not a byte array. This requires major changes to be made in the substrate framework and this process can take a lot of time.

The second approach is to add a new SignedExtension, and double sign the transaction (byte array and human-readable text), it will add more data to extrinsic and will increase transaction validation times, yet it can be implemented without any modifications to the substrate framework. Any parachain can support the app by adding this SignedExtension. SignedExtension can support default trx. signing for backward compatibility.

We would love to hear community and expert thoughts on the above and Invite Parity, Parachains, and the Zondax team to further discussion.

2. Zondax claims: The quote:

Q: “We are shocked that the development plan seems to bluntly claim features and activities that already exist and have been available for a long time”

A: We want to build a universal Ledger app that will support multiple parachains. We ask you to carefully re-read our proposal to clearly understand the exact activities for which we’re requesting the funding. To be specific, funding is required to enable clear signing for all available balance pallets and other developments that require a lot of effort.

There are several issues with Zondax’s approach as we see them:

1. Zondax APPs currently support only 4 main chains: Polkadot, Kusama, Statemine, and Statemint.
2. In order to have Ledger support, Zondax requires each parachain to sign up for their services with no transparency about costs.
3. Zondax’s approach is not universal, doesn’t serve ecosystem interests, and doesn’t provide a universal parachain app in a timely manner. The discussion around our solution has been going on for 6 months plus and we still haven’t moved in the practical direction.
4. There are concerns regarding the cost of the app and its support for the Polkadot treasury. And we believe Zondax should be more transparent in their claims of the audit and support costs.
5. We have never spoken out against Zondax’s solution, and it is very strange for us to see so much negativity coming toward us in recent days. We believe that Zondax’s solution for Polkadot and Kusama should remain in place at least until a better solution is devised.

On the other hand, grants and open source are operating in such a way that if any team can create a better solution, they can compete for funding.

Spending $700k of treasury funds just for support of Zondax’s solution for 4 parachains seems unreasonably expensive to us. Additionally, the entire community would benefit if there was more disclosure about the proposed audit costs and the companies that will be doing the audit.

Finally, we have always stated and continue to say that our solution is the first step toward the right ledger application, and if we as a community can ultimately figure out how to make it better, we will gladly support any such initiative.

Express your opinion on our initiative and support us here!

In the decentralized world, optimization is crucial to enhance the efficiency and scalability of various systems. From distributed computing to network protocols, we continually strive to maximize performance and improve user experiences. The blockchain, with its promise of transparent, secure, and decentralized transactions, is no exception. In this article, we’ll analyze optimization techniques tailored for Substrate blockchains, shedding light on practical tips to elevate the performance of these innovative platforms.

Before we explore the intricacies of optimization in the blockchain space, let us first establish its significance in the broader context of decentralization.

Why We Optimize Systems

Optimization empowers us to streamline processes, minimize resource consumption, and increase system efficiency. It enables us to overcome challenges in scalability, latency, and transaction throughput. Through efficient algorithms, leveraging parallel processing, and optimizing data structures, we can realize the true potential of decentralized systems.

Transitioning our focus to Substrate blockchains, we unravel unique characteristics and challenges they present to us. As a modular framework for building blockchain solutions, Substrate provides a rich set of tools and functionalities. However, achieving optimal performance on Substrate blockchains requires a deep understanding of the underlying technology and thoughtful consideration of design choices. At the end of the day, a faster blockchain means a better product and more possible design choices.

Armed with this understanding, we embark on a practical journey, presenting a range of optimization techniques tailored for Substrate blockchains. By optimizing storage and implementing caching strategies, we provide actionable insights to improve the performance and responsiveness of Substrate-based networks.

Approaches to Optimization in a Centralized World

There are several approaches to optimization in the centralized world. Let’s explore these strategies in more detail:

1. Scaling: Scaling involves expanding the system’s capacity to handle a larger transaction volume. There are two main scaling techniques:

• Horizontal Scaling: This approach involves adding extra servers to the network, effectively distributing the transaction load among multiple nodes. We can accommodate a growing number of users and transactions with horizontal scaling.
• Vertical Scaling: Vertical scaling focuses on enhancing the capabilities of existing servers by upgrading hardware components such as CPU, memory, or storage, allowing us to improve performance by increasing available computational resources.

2. Choosing the Best Instruments: Selecting a programming language, databases, and message queues like Rabbit MQ affects the efficiency of applications. Opting for technologies well-suited to the project enables us to improve performance and streamline development.

3. Parallelization and Asynchrony: Leveraging parallel processing and asynchronous programming techniques allows tasks to be executed concurrently in a multithreaded environment, enhancing overall efficiency.

4. Database Optimization: Optimizing the database architecture and configuration is essential for efficient data storage and retrieval. We can reduce latency and enhance query processing speed through techniques such as indexing, sharding, and data compression.

5. Code Optimization: Choosing the most effective algorithms and data structures for implementing various functionalities within the application is crucial for streamlined functionality. Optimized code enhances the efficiency and responsiveness of the system, resulting in improved overall performance.

6. Caching Frequently Used Data and Query Results: We avoid redundant computations and minimize the load by storing frequently used data in a cache.

Incorporating these optimization techniques into the development process enhances performance, scalability, and user experience. Leveraging the power of optimization, we meet market demands by delivering reliable systems capable of scaling up with a growing market.

Having understood the streamlining options in centralized systems, let’s explore how we can improve blockchain performance for Substrate-based platforms.

Optimizing Substrate Development for Blockchain Performance

When optimizing Substrate development, it’s crucial to understand the differentiating factors between Substrate and traditional backend systems. A significant distinction is the access to storage speeds.

In traditional development, memory calls are often made with little consideration for optimization. However, in Substrate, every memory call is expensive. Additionally, Substrate imposes certain limitations on the choice of tools, parallelism, and caching options.

Below is a table explaining the theoretical approaches to optimize blockchain performance within the context of Substrate:

Although certain limitations exist, we can use caching management and reducing storage calls to achieve notable performance improvement within the Substrate framework.

So, from these theoretical examples, what are the practical steps we can take to optimize Substrate blockchains?

Practical Approaches for Optimizing Substrate Blockchains

Before proceeding, let’s first comprehend how caching works in the Substrate framework:

1. Quick Access: Accessing cached data is much faster than accessing data from storage.
2. Cache Population: Data is written to the cache when it’s first called from storage.
3. Least Used Object Removal: The least used object will be removed if the cache becomes full to accommodate new entries.

Let’s now examine practical ways to optimize Substrate blockchains.

1. Utilize Constants: Storing parameters in constants is preferable to pallet storage for customized pallets. Constants aren’t kept in storage and therefore don’t require resources to read from storage. Although modifying a constant requires updating the chain, the performance improvement is significant enough to outweigh this drawback.
2. Do not iterate on HashMap: EVM developers who transitioned to Substrate frequently use HashMap to store data. Iterations can be costly, and they don’t take advantage of the cache. To address this, we at Equilibrium utilize VecMap — a vector data storage that combines the benefits of a Map interface with high speed.
3. Storing Pallet Parameters: We prioritize a minimal number of data structures and encourage the creation of large ones. It has a negligible impact on performance while reducing the amount of memory calls notably improves efficiency. In our experience, reading/writing a vector with 1k elements is comparable to a single element. Minimizing the number of read/write operations is essential for optimal performance.
4. Storing Dynamic Data: Let’s look at assets as an example. If our chain doesn’t allow users to create new assets, and we often need to access parameters such as price, we can store these parameters in a VecMap instead of a HashMap. This way, the asset will be stored in the cache most of the time, resulting in faster transfers.
5. Using System Account Data: Before executing an extrinsic, Substrate performs two essential tasks: it checks the nonce and deducts the transaction fee. This action consolidates the System storage into the Account and caches the balances storage. In the cases of Polkadot and Kusama, these two storages are merged, enabling a single read-and-write operation to handle both functions. Expanding the account data provides a suitable place to store frequently used account parameters such as scores, ratings, and nicknames. By leveraging this approach, we can avoid excessive interactions with storage and optimize performance.
6. Utilize Off-Chain Workers: Off-chain workers, a powerful Substrate feature, contribute to optimization efforts. They allow delegating heavy tasks to be performed off-chain and only verify the result on-chain. At Equilibrium, we apply this approach to manage margin calls. We utilize off-chain workers to monitor accounts and verify margin calls off-chain. We eliminate the need to check all accounts on-chain, enhancing overall performance.
7. Conduct Extensive Stress Testing: To ensure the optimal performance of our blockchain, we understand the importance of thorough stress testing. While benchmarks provide a preliminary understanding of how complex an extrinsic is, they don’t consider critical factors like caching and storage size, which are essential for performance optimization. That’s why we subject our system to rigorous stress testing.

We develop a deeper understanding of the actual duration of transactions and identify potential areas for improvement through the stress tests. They allow us to fine-tune our system, optimizing it for enhanced performance.

Additional Blockchain Optimization Ideas

In addition to the previous optimization techniques, let’s mention a couple ideas to further enhance the performance of Substrate blockchains.

1. Custom Caching: One way to optimize performance is by implementing custom caching, which involves preloading data when adding an extrinsic (a transaction) to the pool. We can often determine the necessary data and efficiently preload it into the cache by analyzing the extrinsic’s arguments, ensuring faster access.
2. Deparallelizing data access: Currently, the parallelization implementation in Substrate does not allow storage calls and is thus largely ineffective. For Substrate technology to be competitive with, for example, payments giants, deparallelizing data access is mandatory.

These practical optimization techniques for Substrate blockchains allow us to improve system performance. We continue to explore and experiment with optimization techniques to realize the full potential of Substrate-based blockchain systems.

As blockchain technology continues to evolve, achieving seamless communication and interoperability between different chains has become a crucial objective. In this article, we delve into two prominent protocols — Inter-Blockchain Communication (IBC) and Cross-Consensus Messaging (XCM) — that enable secure, permissionless, and trustless transfer of data between blockchains. We will explore both IBC and XCM, their functionality, features, and potential use cases.

At its core, IBC is an interoperability protocol that facilitates the transfer of data, assets, and logic between distinct blockchains. The protocol operates on the principles of simplicity, flexibility, and decentralization, offering a powerful solution for connecting blockchain networks.

Three abstraction layers: channels, connections, clients. Channels to identify application, connections for double identity verification, and clients to track consensus state of recipient chains.

When we send a packet on one chain we will submit a commitment proof, it will be recorded into the state. Then a relayer will construct a packet and add a proof that this was submitted into state and then submit this on the receiving chain which can then verify it using the Light Client of chain A that they have stored on chain B.

There are different Light Clients per consensus type. IBC’s scope has expanded beyond the Tendermint consensus chains, thanks to the efforts of projects like Composable, which now support Substrate-based chains.

On top of clients there are connections. They operate once clients have been set up. It is a double identity verification. Both channels and connections are set up by handshakes.

The last layer of abstraction is channels. They are also set up with a handshake. In combination with the port they identify the application. Channel for a fungible token transfer over IBC could look like transfer/channel-0/base-denom where ‘transfer’ is the port name.

Relaying is permissionless and can be incentivized. IBC v4 and onwards contains fee middleware. Two implementations of relayer software available: one is Hermes developed in Rust and another is Go Relayer.

Let’s look at the IBC packet lifecycle using ICS-20 fungible token transfer standard.

Tokens on the left side are locked up by a user on Chain A, and after the tokens are locked, the packet is sent. The Light Client verification algorithm on Chain B checks whether the tokens on Chain A have been locked and mints IBC vouchers representing tokens of Chain A on Chain B.

Here’s a more generalized packet flow visualization:

This packet flow representation can be applied not only to fungible tokens but also to any data packets. Flow can be done in two different ways: by using interchain accounts or via custom applications.

Let’s look at custom IBC applications first.

Custom IBC applications allow for the development of completely customizable data transfers between chains. The exact requirements for module application to be IBC compatible can be found in the documentation. Specific application logic can then be added to such IBC compatible modules. Any data can be sent to the corresponding counterparty module. ICS-x means that the token will have a number instead of the ‘x’ which refers to a particular application.

Let’s now examine interchain accounts.

The interchain accounts option allows the use of functionality on Chain B from Chain A without leaving Chain A’s environment.

Chains can implement both or either controller or host functionality. Host chain hosts ICA, executes sent txs. Controller chain triggers actions to be executed on the Host chain.

Let’s now explore a scenario where the relayer didn’t pick up the packet.

To avoid funds getting locked up forever a timeout functionality is implemented. The cool thing about IBC is it allows you to query not only receipts but also non-receipts. Such a query allows the user to submit a timeout command and revert the original send packet logic.

ICA have ordered channels. If such a channel has a timeout it is closed automatically.

Functionality that doesn’t go in the IBC core can be used as middleware and reused for different applications thus building a middleware stack.

This diagram shows that we can keep stacking middleware and create functionality that way. Here packet and write_ack go from base application to Core IBC. Handshake, acks and timeouts go from Core IBC through the middleware to the base application. Order matters and must be replicated on the counterparty chain.

XCM is a cross-chain messaging protocol that enables the transfer of data and assets between chains in a more sophisticated and programmable way than ever before. XCM V3 includes improvements in three key areas: expectations and branching, introspection and safe dispatches, and asset exchange and NFTs.

Let’s now examine expectations and branching in more detail.

There are three new instructions: ExpectAsset, ExpectError and ExpectOrigin. They are related to three existing registers: Holding, Error, Origin. This allows for branching: changing the flow depending on errors thrown.

Safe dispatches allow for version control of destination chain and specific pallet. There is a new register called ‘Transact Status Register’ and four new instructions: QueryPallet, ExpectPallet, ReportTransactStatus, ClearTransactStatus. The new register holds the result of the most recent transact operation. QueryPallet gives back the instances of a specific pallet or module. ExpectPallet throws an error if the expected version does not match the one we get back. ReportTransactStatus reports what the Transact Status Register holds and ClearTransactStatus clears the data.

The goal of these statuses is to ensure no unexpected behavior is happening.

The second big category introduced in XCM v3 is Functional Multichain Decomposition. It is designed to allow for building utilizing logic from multiple chains. The changes here can be grouped into three categories:

• Remote Locking
• Context/ID for tracking messages & queries
• Asset Namespacing

Remote Locking enables chains to use assets in other chains. Four new instructions here:

• LockAsset
• UnlockAsset
• NoteUnlockable
• RequestUnlock

One of the goals for Functional Multichain Decomposition is to enable tracking XCM messages. A new register ‘Topic’ is introduced. It can be set to any value and used as an ID by itself or in combination with ‘Origin’ to create a unique identifier.

There is a way to let ExmExecutor know about the context of the instruction using the XcmContext struct. It has three fields: Origin, XcmHash, Topic. This allows to track XCM message’s context and thus have an application spread between different shards.

The third big area of note is bridging. The four key improvements here are:

• Universal Location
• Message Exporting
• Two stage Send and Export
• Logical Origins

Universal Location is a new and unique location, a parent of all locations (different consensus systems). It encompasses relay chains and parachains. It has no parent and allows to use ‘Context’ for locating within the Universal Location.

There are three new SendXcm impls to manage routing over a bridge. They cover three scenarios:

1. The bridge is local
2. The bridge is in Local consensus but not on local chain (no fees expected)
3. The bridge is not local (fees expected)

Two stage Send and Export means that SendXcm is now a two-stage process: validate and deliver. Validate does price discovery and returns a ticket. Deliver executes the transaction.

The rise of IBC and XCM protocols represents significant milestones in achieving seamless communication and interoperability across blockchain networks. Through their secure, permissionless, and trustless nature, IBC and XCM empower developers to create decentralized applications that transcend the boundaries of individual chains. By enabling data transfer, asset exchange, and sophisticated programmability, these protocols pave the way for the next generation of blockchain innovation, facilitating collaboration, scalability, and enhanced user experiences in the decentralized ecosystem.

EQ Lab develops a variety of different products on multiple blockchain platforms. Among others, there is am EVM-based decentralized lending protocol that allows users to take up to 20x leveraged long and short positions on crypto assets across different DEX-es and AMMs. In this article we will explore how this product utilizes binary heaps to handle margin calls.

Pools

The protocol is comprised of liquidity pools. Each pool consists of a quote asset (stablecoin) and a base asset (risk asset). For each pool there is a corresponding AMM pool where quote and base assets can be exchanged. Lending pools allow to deposit base or quote asset, go long or short (borrow the other asset with up to 20x leverage), withdraw base or quote asset, and close long/short positions.

Four indexes are calculated for each pool. They are baseCollateralCoeff, baseDebtCoeff, quoteCollateralCoeff, quoteDebtCoeff. These are used to determine interest rates.

Positions

There are three types of positions: Lend, Long, and Short When a user creates any of these positions a discounted balance is stored instead of the “real” balance. This is how it is calculated:

discountedBalance = realBalance / coeff

There are separate coefficients for Lend, Long and Short positions. For example if a Lend position is created by depositing quote asset the following calculation applies:

discountedQuoteAmount = realAmount / quoteCollateralCoeff

The calculation for Short and Long positions is as follows:

discountedBaseAmount = realAmount / quoteDebtCoeff

Short and Long positions are then stored in two separate collections. They are sorted in descending order of debtAmount/collateralAmount. For short positions this is calculated as baseAmount/quoteAmount, and for long positions the calculation is quoteAmount/baseAmount.

These sorted positions are stored in a Max binary heap.

Any user action that changes a position’s quoteAmount/baseAmount ratio triggers a recalculation of the binary heap such that the first element is always the riskiest position.

Interest rates

Interest rates are scaled proportionally to asset volatility and leverage. Total long leverage and total short leverage is calculated for each pool. Users who take up long or short positions pay interest fees to collateral providers. Fee accrual is done by changing baseCollateralCoeff, quoteCollateralCoeff coefficients. Fee write-off occurs by modifying the baseDebtCoeff and quoteDebtCoeff.

Margin calls

User action triggers a heap check of long and short positions leverages. Leverage is calculated for the riskiest position (heap root). It is then compared to the max leverage pool parameter. If the position’s leverage exceeds max leverage, the position is liquidated. In this case collateral is swapped and used to cover liabilities. The rest is then distributed between lenders. If there is not enough collateral to settle, the lenders cover the difference. These actions are performed by modifying baseCollateralCoeff or quoteCollateralCoeff. This way individual balances don’t need to be changed.

This design allows to run an automated liquidator as well as potentially implement no-liquidation systems in future versions of the protocol. It is more capital efficient compared to designs that implement collateral, debt and balances positions for each user because liquidity can be reused: the same capital can be used to go both long and short simultaneously. This could ultimately result in a superior product and user experience.

Ledger integration with Polkadot parachains is crucial but presents challenges, including extended response times and non-intuitive application experiences due to unique account derivation paths.

With no dedicated Ledger app for parachains, users risk losing access to funds due to insecure browser extensions and mobile apps. To protect against this danger, we suggest developing an application with a single signature standard usable across multiple parachains — much like Keplr in Cosmos or Metamask on Ethereum-based blockchains.

Below is a table summarizing the challenges and impact of the current Ledger integration model and the recommendations to streamline Polkadot-Ledger integration:

A Universal Ledger App for Improved Security and User Experience

Learn about how we propose to make a unified Ledger app by eliminating data encoding on the device in our blog post: Proposed Solution For Ledger Integration Compatible With All Polkadot Parachains. We provide a demonstration of one potential implementation with transactions to three parachains in what we believe to be a reasonable compromise that could benefit the entire ecosystem!

If you have coded on Solidity, you do know that, contrary to its commonly-praised simplicity, this language has many inherent peculiarities, along with the Ethereum run-time environment itself. And if you aren’t fully armed against such, they can greatly increase the time for debugging, giving you and your PM much of a headache.

For instance, there are several different types of memory available to the contract. Another tricky thing is that the basic data type is a 256-bit integer (32 bytes) and the byte order is not little-endian like in x86, but big-endian. What is more, the solidity compiler may generate an error without specifying a line or a source file which it struggled to compile, and some seemingly innocuous and concise language constructs can unfold into a large number of inefficient bytecode during compilation.

To better understand what exactly the compiler turns solidity code into, you can use disassemblers and decompilers. But while disassemblers are pretty hard to use on their own, the output generated by a decompiler can differ drastically from the original contract code. Still, there is a kind of a ‘magic wand’ to sort this out.

Truffle, the most popular framework for working with the code on Solidity, generates plenty of other useful data during compilation, apart from the bytecode of the contract. We can use this data to conveniently match the source code with the instructions and the other way around.

In our post Solidity Source Mapping explore the way Truffle data gives you the insight into how your code actually behaves and what exactly it does in the blockchain. We walk you step by step through the Source mapping process, which is also a really convenient way to analyze bottlenecks in your code.

Stay tuned! Yours, EQ LAB Team

New to trading? Try crypto trading bots or copy trading on best crypto exchanges

Solidity Source Mapping was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Unlocking Ethereum liquidity is widely considered of paramount importance to any DeFi protocol’s success no matter the chain it chooses to launch on.

This DefiLlama chart illustrates almost 60% of all Defi TVL is locked on Ethereum. This makes bridging liquidity from Ethereum a high priority for Equilibrium.

This article will examine Equilibrium’s bridging solution that allows for cross-chain transfers between EVM networks and Polkadot parachains. It’s a unique contribution to the parachain ecosystem since it pioneers the concept of one parachain using another as a bridge. A brief overview of the underlying tech will also be provided. Let’s start with the basics.

Multichain is an open-source project that builds interoperable infrastructure for cross-chain interactions. It supports over eighty blockchain networks with approximately$1.6B TVL. Multichain has a history of reliability and trustworthiness stretching back to July 2020. Let’s examine Multichain’s Cross-Chain Bridge and Router.

Multichain Cross-Chain Bridge

The bridge fundamentally allows an asset to be sent from one chain to another. Let’s briefly describe how it works.

First an asset is locked on a token wrapper controlled by the Router contract on the source chain side. An MPC (Multi-party computation) Network with 28 validators verifies the transactions on the source chain and then signs token minting or withdrawal transactions on the target chain. A wrapped asset is then minted or native asset is withdrawn on the target chain. Wrapped assets can be burned to facilitate transfers from the target chain to the original one.

More info on the Cross-Chain Bridge.

Active MPC validator set can be found here.

Multichain Cross-Chain Router

The Router enables asset transfers for native tokens and those created with Multichain Bridge (bridged) between two or more chains. Liquidity pools support native assets since Multichain can not mint or burn those tokens. This requires tokens to be supplied to liquidity pools externally. Bridged assets do not require liquidity pools because Multichain controls the supply of those assets by minting and burning bridged tokens.

It’s also possible to combine native and bridged assets when a project adds support for extra chains via the router. Tokens on the chains supported by Multichain are considered bridged, while pre-existing tokens are considered native.

More info on the Cross-Chain Router.

SMPC network

Multichain uses a Secure Multi Party Computation (SMPC) network of nodes. These nodes generate parts of the private key for signing transactions. An algorithm selects a set of nodes from the network to do this. Selected nodes then sign transactions collectively. This mechanism is used for every supported network.

More info on SMPC.

Moonbeam EVM parachain

Moonbeam is a parachain on Polkadot designed as an onramp for developers. It’s an Ethereum-compatible L1 smart contract platform. Moonbeam is one of the ecosystem’s biggest and best-known projects, the first winner of parachain auctions on Polkadot. Moonbeam enables developers to go cross-chain with their existing Ethereum dapps as well as create new cross-chain projects.

XCM

XCM stands for Cross-Consensus Message. It is how Polkadot brings interoperability to its projects. XCM format defines how messages are sent between blockchains, effectively connecting parachains to the relay chain and each other. This delivers on the promise of cross-chain application interoperability as more and more projects launch on Polkadot parachains allowing users to interact with all of them from a single dapp.

The main use case for XCM currently is accessing tokens in cross-chain dapps. Smart contracts on Moonbeam can communicate directly to perform transactions and other activities.

More info about XCM on Polkadot Wiki and Moonbeam.

XC-20 tokens

XC-20 is a token standard for ERC-20 tokens on Moonbeam. These tokens are cross-chain-ready and transferable across the entire Polkadot ecosystem. This is useful for applications that want to integrate native tokens as ERC-20s.

See Moonbeam docs for a detailed breakdown of how XC-20 works.

How it all comes together on Equilibrium

In Equilibrium’s case, both EQ and EQD tokens are controlled by Multichain, meaning that Multichain routers have minting and burning rights for these tokens. These minting and burning actions allow for control over the supply of these assets on the chain where the smart contract resides. This means all that is required for the bridge to work is a supply of assets on the chain where the token was originally minted. This is what bridging looks like for EQD:

The Equilibrium team developed a proxy contract that implements AnycallProxyBase interface and allows token transfer from Moonbeam to another parachain in the Polkadot ecosystem. This solution may be used by any team which wants to use a Multichain bridge in their parachain.

For a more in-depth look into how it works see github.

Moonbeam contains system contracts that connect EVM and Substrate parts of the network.

Using this contract, users may transfer XC-20 tokens from their Moonbeam EVM address to another parachain with substrate-type addresses.

The xTokens -transfer method allows sending XC-20 and pays fees in this token.

Using this method will move XC-20 tokens from a user to a sovereign account of the destination parachain in Moonbeam. The same value will be deposited to a recipient in the destination parachain.

Equilibrium put together two great things — a custom proxy call and “xTokens” contract and made automated deposits to Equilibrium or any other parachain from Multichain-supported networks possible.

Here is a generalized overview of what happens to the tokens under the hood using WBTC, ETH and USDC as an example:

Equilibrium implemented `XcmTransferProxy` for transferring tokens from Moonbeam to another parachain without additional user transactions. The code for this is on Github.

Here’s how it streamlines the token transfer process:

Withdrawal flow optimization

One of future Moonbeam runtime releases will enable the EVM call by XCM feature. It will be a powerful tool enabling interaction with EVM contracts on Moonbeam from any parachain.

Withdrawals from Equilibrium or any parachain will be enabled without additional user transactions on Moonbeam after the feature is released.

This is what withdrawal flow looks like now compared to after optimization:

Bridging liquidity across different chains is a complex and challenging process to streamline. Equilibrium has made a momentous step forward by developing a custom bridging solution. It benefits the project and ecosystem as a whole in two significant ways. Firstly it unlocks Defi TVL on Etherium and brings it to Polkadot parachains, and secondly, it facilitates the realization of Equilibrium’s mission to make EQD a cross-chain stablecoin.

This kind of cooperation between Equilibrium and Moonbeam in developing a solution that can be used by all parachains and benefits the entire ecosystem is the manifestation of a long-term vision of interoperability and value accrual that is now becoming a reality.

EQ Lab is a software engineering company specializing in building robust and innovative Web3 products on top of multiple decentralized platforms, including Ethereum, Polkadot, TON, and others. Our core expertise lies in the field of finance and decentralized economy but is not limited to ranging from high-load infrastructure to applications incorporating NFT-based structures.

The flagship project in our portfolio is Equilibrium, a cutting-edge all-in-one DeFi platform that leverages the power of the Substrate development framework and Polkadot’s parachain architecture. It provides users with a seamless and secure experience offering a wide range of features such as a decentralized stablecoin, lending, borrowing, and trading. Equilibrium’s mission is solving capital inefficiency in DeFi, making Equilibrium a versatile and powerful solution for high-leverage yet safe operations with digital assets.

What sets EQ Lab apart is our valuable blend of financial expertise and technical know-how.

Some of the team’s notable past achievements include:

• GMRA-compliant p2p lending protocol on Ethereum called Nitrogen. It supported various ERC-20 tokens and sophisticated risk management models from TradFi repo markets.
• EOSIO-based collateral-backed stablecoin protocol (EOSDT). The protocol leveraged EOSIO blockchain speed and deferred transactions to optimize liquidations thus lowering collateral requirements.
• Bridge between TON blockchain and heterogenous networks. It adhered to a federated relay structure and was built using TON’s Fift and C++ languages.
• Sophisticated risk-based approach to collateral backed loans on Polkadot which allowed to build a unified money-market, a stablecoin and a spot margin trading engine with leverages up to 20x.
• The Curated — a digital catalog that allows for purchasing of digital art collections picked by a panel of experts.
• Expertise and extensive research in the field of ZKPs allowed to build a proof of concept for rust-based blockchains (Substrate and Polkadot in particular).

As you can see from the list above, it’s not just Polkadot at the center of EQ Lab focus. The Substrate experience means the team is well-versed in building complex custom modular blockchain solutions. XCM technology is one example that has the potential to be utilized to transfer messages between different ecosystems and implemented outside of Polkadot.

EQ Lab team’s first-hand experience building on Polkadot has led to a number of unique technical solutions on offer to help less experienced teams and projects looking to get into the space.

Here is a non-exhaustive list of custom features and areas of expertise EQ Lab team perfected while building Equilibrium:

• Unique bailsmen liquidation mechanism
• Robust oracle solution
• XCM implementation experience
• Testnets and full emulation integration testing
• Custom assets and balances, balances double accounting
• Bridging solutions for EVM chains
• Blockchain backend development
• Custom balance checker and algorithmic asset management
• Blockchain storage and trx throughput optimization

The aim is to create innovative and secure DeFi solutions that meet the needs of our clients using our extensive knowledge and experience. Partnering with EQ Lab will give you access to our team’s expertise and resources and open the doors to DeFi.