Author: Written with the help of OpenAI

Read: 20 min

Description: Provide basic understanding of different elliptic curves families, which is commonly used in cryptography.

Body:

So here are some Elliptic curves:

• The NIST P-256 curve, which is defined by the equation y^2 = x^3 - 3x + b, where b = 41058363725152142129326129780047268409114441015993725554835256314039467401291.

• The NIST P-384 curve, which is defined by the equation y^2 = x^3 - 3x + b, where b = 39402006196394479212279040100143613805079739270465446667948293404245721771496870329047266088258938001861606973112316.

• The secp256k1 curve, which is defined by the equation y^2 = x^3 + 7, where a = 0 and b = 7.

• The NIST P-521 curve, which is defined by the equation y^2 = x^3 - 3x + b, where b = 0x01FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF.

• The Brainpool P-256r1 curve, which is defined by the equation y^2 = x^3 + ax + b, where a = -3 and b = 0x52036CEE2B6FFE738CC740797779E89800700A4D4141D8AB75EB4DCA135978A3E.

• The secp192r1 curve, which is defined by the equation y^2 = x^3 + ax + b, where a = -3 and b = 0x64210519E59C80E70FA7E9AB72243049FEB8DEECC146B9B1.

And the differences between these curves:

1. The main difference between the NIST P-256 and NIST P-384 elliptic curves is the size of the prime number that defines the curve. The P-256 curve is defined using a 256-bit prime, while the P-384 curve is defined using a 384-bit prime. This means that the P-384 curve provides a higher level of security than the P-256 curve, since it is more difficult to find the discrete logarithm of a point on the P-384 curve than on the P-256 curve. However, the increased security of the P-384 curve comes at the cost of slower performance, since operations on the P-384 curve are more computationally intensive than on the P-256 curve. Therefore, the choice of which curve to use depends on the specific security and performance requirements of the application.

2. The secp256k1 and NIST P-256 elliptic curves are both defined over the same field (the set of integers modulo a prime number), but they have different equations and different values for the constants in those equations. The secp256k1 curve is defined by the equation y^2 = x^3 + 7, while the NIST P-256 curve is defined by the equation y^2 = x^3 - 3x + b, where b = 4105836372515214212932612978004726840911444101599372555483525631403946740129.

The main difference between these two curves is that the secp256k1 curve has a much simpler equation, which makes it more efficient to work with. This makes it well-suited for applications such as cryptocurrencies, where fast and efficient elliptic curve operations are important. On the other hand, the NIST P-256 curve provides a higher level of security than the secp256k1 curve, since it is more difficult to find the discrete logarithm of a point on the NIST P-256 curve than on the secp256k1 curve. Therefore, the choice of which curve to use depends on the specific security and performance requirements of the application.

The above curves are represented in the Weierstrass form, the most common form of representation when you Google ellipitc curve. There are also various other forms of elliptic curve representation, which can provide certain comptuational advantage under certain conditions.

• The Weierstrass model, which uses a standard cubic equation to define the curve and projective coordinates to represent points on the curve.

• The Twisted Edwards model, which uses a quadratic equation to define the curve and affine coordinates to represent points on the curve.

• The Montgomery model, which uses a quartic equation to define the curve and projective coordinates to represent points on the curve.

• The Edwards model, which uses a quadratic equation to define the curve and projective coordinates to represent points on the curve.

And here are some curves that uses the Twisted Edwards model:

• The ed25519 curve, which is defined by the equation -x^2 + y^2 = 1 + dx^2y^2, where d = -121665/121666. This curve is commonly used in applications such as digital signatures and key exchange.

• The curve25519 curve, which is defined by the equation -x^2 + y^2 = 1 + dx^2y^2, where d = 37095705934669439343138083508754565189542113879843219016388785533085940283555. This curve is similar to the ed25519 curve, but is not a standard NIST curve.

• The Ed448-Goldilocks curve, which is defined by the equation a = 39081 and b = c = 2000000000000000000000000000000000000000000000014def9dea2f79cd65812631a5cf5d3ed. This curve is a variant of the Ed448 curve, which is defined by the equation a = -39081 and b = c = 2000000000000000000000000000000000000000000000014def9dea2f79cd65812631a5cf5d3ed.

Moving on from regular elliptic curves, there are also pairing-friendly elliptic curves. Pairing-friendly elliptic curves are a special type of elliptic curve that are well-suited for use in certain cryptographic protocols that involve a mathematical operation known as a "pairing". There are many different types of pairing-friendly curves, and the specific curves used can depend on the specific requirements and preferences of the application. Some examples of pairing-friendly curves include:

• The Barreto-Naehrig (BN) curve, which is defined by the equation y^2 = x^3 + b, where b = 0x202FEB054934C0AEE7E84DCCFE1E7F9DF25CFDADF7E31E16A2360C1A39C6D3D588A3CC8B9F65784D2917F7042BBBE23E45A2E1D2CE03FE2E1F8F8A9CA46D191B.

• The Barreto-Lynn-Scott (BLS) curve, which is defined by the equation y^2 = x^3 + b, where b = 0x2. This curve is commonly used in BLS signature schemes.

• The Boneh-Franklin (BF) curve, which is defined by the equation y^2 = x^3 + b, where b = 0x12C9D9585769C049C5D5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5B5 And these curves can be used with various pairing functions such as:

• The Tate pairing, which is a type of pairing that can be used with any elliptic curve.

• The Weil pairing, which is another type of pairing that can be used with any elliptic curve.

  Things work pretty much the same in pairing-friendly curves, just that they support the extra functionality of pairing. Pairing is a mathematical operation that takes two points on an elliptic curve and maps them to a specific value in a finite field. This operation has specific properties that make it useful for certain cryptographic protocols, such as those used in identity-based cryptography and attribute-based encryption.

  To highlight the power of pairing, let's examine an example BLS aggregation signature protocol. The BLS aggregation signature protocol is a technique for combining multiple individual BLS signatures into a single signature that is smaller and more efficient to verify. This technique is useful in applications where many different parties need to sign a message or document, as it allows the signatures to be combined into a single signature that can be verified more efficiently. The specific steps involved in the BLS aggregation signature protocol can vary depending on the specific implementation and the specific requirements of the application. However, in general, the process for aggregating BLS signatures using the BLS aggregation signature protocol involves the following steps:

1. Each party who needs to sign the message or document generates a private key and a corresponding public key, using the BLS curve that is being used for the signatures.

2. Each party then signs the message or document using their private key, resulting in an individual BLS signature.

3. The individual BLS signatures are then combined into a single signature using a specific aggregation algorithm, such as the BLS threshold signature scheme. This algorithm allows the individual signatures to be combined into a single signature that is smaller and more efficient to verify.

4. The resulting aggregated signature is then verified using the individual public keys of the parties who signed the message or document. (And the only reason why this is possible, is because of pairing's property)

Overall, the BLS aggregation signature protocol is a technique for combining multiple BLS signatures into a single signature that is more efficient to verify. This technique is useful in applications where many parties need to sign a message or document, as it allows the signatures to be combined into a single signature that can be verified more efficiently.

Another interesting fact is that for Elliptic curves such as BLS curves, there are also various families. As mentioned earlier, BLS is a family of pairing-friendly elliptic curves that are defined by the equation y^2 = x^3 + b, where b is a specific value. For example, the most famous family is the BLS12 curve family, which is a specific subfamily of BLS curves that are defined by the equation y^2 = x^3 + b, where b is chosen such that the resulting curve has specific properties that make it well-suited for use in cryptographic protocols that involve a pairing operation. There are other families of BLS curves besides the BLS12 family that are defined by the equation y^2 = x^3 + b, where b is a specific value. These other families of BLS curves may have different properties and may be well-suited for different applications than the BLS12 family of curves. Some examples of families of BLS curves that are not part of the BLS12 family include:

• BLS48: This is a family of BLS curves that are defined by the equation y^2 = x^3 + b, where b is chosen such that the resulting curve has specific properties that make it well-suited for use in protocols that require efficient scalar multiplication operations.

• BLS48-581: This is a specific curve in the BLS48 family that is defined by the equation y^2 = x^3 + b, where b = 0x24AA2B2F08F0A91260805272DC51051C6E47AD4FA403B02B4510B647AE3D1770BAC0326A805BBEFD48056C8C121BDB8. It is commonly used in protocols that require efficient scalar multiplication operations.

• BLS24: This is a family of BLS curves that are defined by the equation y^2 = x^3 + b, where b is chosen such that the resulting curve has specific properties that make it well-suited for use in protocols that require efficient pairing operations.

• BLS24-377: This is a specific curve in the BLS24 family that is defined by the equation y^2 = x^3 + b, where b = 0x1A0111EA397FE69A4B1BA7B6434BACD764774B84F38512BF6730D2A0F6B0F6241EABFFFEB153FFFFB9FEFFFFFFFFAAAB. It is commonly used in protocols that require efficient pairing operations.

In conclusion, elliptic curves are a mathematical concept that is used in many different fields, including number theory, algebraic geometry, and cryptography. In cryptography, elliptic curves are used to define specific curves that are well-suited for use in a variety of cryptographic protocols, such as public key cryptography and digital signatures. Elliptic curves are defined by equations of the form y^2 = x^3 + ax + b, where a and b are specific values. These equations have specific properties that make them useful for cryptographic applications, such as the ability to define a group structure on the points on the curve. There are many different types of elliptic curves that are used in cryptography, including Weierstrass curves, twisted Edward curves, and BLS curves. Each of these types of curves has specific properties that make it well-suited for different applications. Overall, elliptic curves are a powerful mathematical concept that is used in many different fields, including cryptography. These curves have specific properties that make them useful for cryptographic applications, and they are commonly used in a variety of cryptographic protocols.

Author: Not gonna tell u my name

Last Modified: 26-07-22

Read: 8 min

Description:

Move is an executable bytecode language used to implement custom transactions and smart contracts designed by Meta Engineers (who had left to build Aptos & Sui). The Move ecosystem refers to any applications involving the Move Language, including Aptos, Pontem, Hippo Labs, Martian and more.

TL;DR

• Move is a bytecode language used by several blockchains such as Diem, Aptos & Sui

• Aptos is currently one of the fastest layer one blockchains out there, setting a record of 180k TPS, Solana only claimed 50k TPS and operated at ~5k TPS.

Overview

To understand the Move Ecosystem, one should first take a look at the history of the Move Programming Language. Move Programming Language was initially developed within Meta (Facebook) for a blockchain project known as Libra. Libra later got rebranded to Diem on Dec 1st 2020, and sold to Silvergate in Jan 2022 after facing a lot of pressure from regulators. The developers of Diem also took off midway to create their own blockchain, known as Aptos, in order to put their ideas into motion, ditch bureaucratic red tape, and build an entirely new network from the ground up that brings them to fruition. Some developers also went on to create Sui, which is another blockchain that uses a slightly modified Move Programming Language, and another consensus algorithm. As of July 25th, Aptos has managed to raise $350 million (USD) prior to their mainnet launch, which is scheduled to happen at the end of September or later. And it is one of the record breaking chains in terms of technical performance and funds raised, and also the center of Move Ecosystem currently.

Google Trend

Before we dive into the numbers & statistics of Aptos, let's first take a look at the three most popular cryptocurrency (excluding stablecoins & memecoins)

Bitcoin is still the most popular cryptocurrency, but what is interesting is that people are getting more & more interested in Solana during the years of 2021-2022. While it is still hard to say if Solana will overtake Ethereum in the next bull run, Defi is definitely no longer limited to Ethereum and bleeding into other ecosystems.

Now let's take a look at some of the hot coins which Centralized Exchanges have listed this year. Surprisingly, Aptos is not the last and had comparable pre-launch attention.

We can see that Aptos received the most attention when they first announced themselves to the world, and a sudden boost in attention again when they launched their incentivised testnet program.

Twitter

Let's take a look at various layer ones' (L1) Twitter popularity. Twitter popularity often indicates general public interest in the blockchain. The key indicator over here would be the number of followers. Aptos is currently in the lead for chains that have yet to launch mainnet. And it does have the potential to grow into one of the largest L1s. Using Apefluencer, we can also see that Aptos is really popular within CT.

Chains that have launched Mainnet

Chains that have yet to launch Mainnet

Discord

Discord has always been a good indicator for developer & degen activity on a blockchain. Aptos perform extremely well over here (more activity than Avalanche, Polygon, etc) and it is possible that Terra's crash has freed up a lot of Rust developers (Move is Rust based) into cryptospace.

Telegram

Telegram best represents the amount of VCs and airdrop hunters which are detrimental to the price action of the cryptocurrency. However, Aptos has not announced any public rounds and seems to be fully funded by institutions. Tokenomics are still not known and it is hard to do an accurate measurement as of now.

Are we bullish?

The initial interests surrounding Aptos seem to be positive; made by ex-Meta engineers, deep funding by reputable VCs, sufficient interest in CT, superior developer activity on discord. However, it is hard to say if it will last. But it's definitely worth investing in the Move Ecosystem. As mentioned, Move is based on Rust programming language, a widely used programming language for smart contracts. The skills will be portable to existing chains and relevant outside of crypto. There is no doubt Aptos will become the top 100 coins upon launch and supporting the infrastructure will prove valuable to companies such as ChainUp, which offer exchange software services.

Aptos current ecosystem

Let's take a deep dive into the current Aptos's Eocsystem pre-launch.

We have Pontem Network which is a company building different kinds of applications on Aptos, including bridges, DEX-es, IDEs and more.

Plenty of candidates for wallet software and providing SDKs (image on the left). And lots of the Defi protocols (image on the right). It is rare to see developers building applications on top of a blockchain before launch (apart from EVM chains which are basically fork, rinse & repeat), in a foreign runtime.

However, we do need to take note that despite seeing so many applications building on Aptos, many of these projects will struggle or fail to deliver. Expectations may not be met and unforeseen issues will happen. And ultimately, Aptos Ecosystem is still way smaller than mature ecosystems such as that of Ethereum.

Conclusion

The future of Move ecosystem is definitely bright & exciting. While it is uncertain if Aptos will become a successful L1 blockchain, investing time & resources on Move ecosystem can prove to be rewarding in the long run. It is advisable to participate in the current ecosystem (in Testnet) to familiarize oneself with Move and be equipped for the future of Web3.

Links

https://aptoslabs.com/

https://aptoslabs.medium.com/

https://twitter.com/AptosLabs

https://github.com/aptos-labs

http://discord.gg/aptoslabs

Disclaimer

Do note that this article is written back in May. Circumstances may have change and no longer applicable today.

Miner extractable value (MEV) is a measure of the profit a miner can make through their ability to arbitrarily include, exclude, or re-order transactions within the blocks they produce.

Ethereum is where most of the MEV action happens, while there are MEV to be earn by miners/validators on other types of blockchain, Ethereum is the father of Defi and has the most value to be extracted.

Flashbots

Flashbots is a research and development organization working on mitigating the negative externalities of current Maximal Extractable Value (from now on MEV) extraction techniques and avoiding the existential risks MEV could cause to state-rich blockchains like Ethereum.

And utilizing the network is easy, users just need to update their RPC endpoint to rpc.flashbots.net

However, trivial transactions like approving and transferring cryptocurrency will not need flashbot network as there are practically no additional value to be extracted apart from the usual gas fees.

Real utility for users

The real utility & power comes when users only need to pay when their transactions go through. And they do not even need to fund their transactions; they can pay directly from the profits they made from the transaction.

This involves requiring the transactions to have block.coinbase.call implemented so that users can pay directly from the contract. But not every contract out there on Ethereum will implement such a function, so how do users deal with contract calls that did not implement?

Luckily, there are public smart contracts out there designed to invoke any contract call and wrapping it with the payment function block.coinbase.call so that anyone can use it without worried about the contract implementation.

https://etherscan.io/address/0x0000feE6275DaB194Ab538A01dD8B18B02b20000#code

Since these contracts code are verified and open source, it will also imply that people can steal your alpha/strategy as people do stare at these contracts and analyze the transactions. Thus, professional searchers often deploy their own contracts to make it harder for people to observe and learn their strategy.

But what’s really awesome about all of this is that as long as you have a good strategy, you can make money out of thin air.

Miners

Miners extract these value from the transaction as users bid using Ether for their transactions to be included. This would mean that profits from obvious strategies like arbitraging will end up in the miner’s pocket and market makers (as the highest bidder wins). Users will need to come up with their own creative strategies to make money from transactions so that no one will outbid them.

Currently, Ethermine is also running their own flashbot relay, a different one from the public using this endpont mev-relay.ethermine.org.

However, Ethermine does some weird stuff and the winning bids does not necessary goes to the highest bidder. In the example shown below, we can see an arbitrage transaction is worth $4k and the user did not need to have their profits extracted by the miner at all! The user simply just paid the usual 1 Gwei gas fee as priority fees and easily made $4k.

The reason is simple, the block is mined by Ethermine itself and they own the account that made the profitable transaction. So while there are bidders who are willing to bid a higher price for the exact same transaction, Ethermine’s will prioritize their own one unless the bidder is willing to pay more than $4k.

And why can Ethermine afford to do these kind of stuff and get away with it? That is because they are the largest miner on Ethereum and mines about ~30% of the blocks. So they do get a say on how transactions should be ordered most of the time on Ethereum. This also allow Ethermine to pay the most competitive rate for people contributing to their mining network, solidifying their position as the number one miner.

And this begins to spiral out of control as common investors decide to also sell their UST at a lower price, fearing that UST will go to zero. As billions of Luna was sold, investors begin to fear even more as the demand of Luna is essentially what backs UST. And with the price action of Luna, it seems like there is suddenly no more demand for Luna.

The UST depegging event continued on and dipped all the way to $0.60 on that day.

However, that was not the end. @stablekwon, @LFG_org and other larger Terra players did not make any formal announcements on the measures to fix the depeg after the relief bounce and remained silent.

The fear quickly got to the investors again as they proceed to sell their UST at a loss when they see the price of Luna dropping.

People were hoping for a solution from the Terra team. And when the announcement came, it was not what they expected:

There was an immediate relief bounce after breaking the silence, but the resolution was to continue printing Luna to save UST. This solution was clearly not feasible anymore, all it took was 1 day for the mass public to join the Luna shorting fest as arbitragers toss Luna onto exchanges. Thus UST also began to decline.

On May 11th, centralized exchanges had to severely reduce their leverage on futures and margin trading pairs. But it wasn’t enough. Luna’s price continue to decline, and reached a dollar. And that wasn’t the end, Luna’s price continue to decline on May 12th to less than $0.000001 on many centralized exchanges by the end of the day. Binance had to delist all their Luna and UST trading pairs (including margin & futures), leaving only LUNA/BUSD and LUNA/UST to prevent people from shorting further.

Throughout the entire event, UST continues to decline and reached an all time low of $0.03. The Terra blockchain also had to halt due to the transaction volume on the chain involving the minting of Terra.

Terra then made an announcement on May 13th to officially halt the chain permanently until a resolution despite a blockchain restart earlier.

At this point, Luna cryptocurrency has officially become a meme coin where people were simply buying for the fun & volatility, just like Doge & Shiba.

Terra’s great meltdown has taught us a lot of things. Apart from doing your own research, always prepare for a black swan event and hedge your investments, be it crypto or traditional stocks.

Lending primitives

Non-custodial liquidity markets

How the protocol works is very simple. Depositor deposit crypto into the protocol to earn interests. Borrowers can borrow funds from the protocol and pay an interest when returning the loans. The liquidity of the borrowed funds will stem from the liquidity provided by the depositors.

In order to ensure that the loans will be returned, borrowers typically need to put down a collateral that is of equal value as the loans. And if the loans are not repaid, the borrower’s collateral assets will be liquidated to cover the loss. These loans are therefore not the undercollateralized loans we typically see at traditional banks and are typically used for leveraging and opening short positions.

Nonetheless, from the depositor’s point of view, it still works the same way: deposit currency and earn interests. The interests will be determined by the utilization ratio, which is how much and how long the underlying asset is borrowed. This makes sense as the interests depositors earn comes from borrowers repaying their loans, and if the borrowers borrow more and for a longer period of time, the depositors should naturally earn more.

Flash loan

Flash loan is a powerful tool & interesting concept which does not exist in traditional finance. Borrowers do not need to deposit any form of collateral at all and it is a type of undercollateralized loans. Flash loans does sounds to good to be true, and hence there is a caveat. And that is flash loans needs to be return within one transaction block, else the loan never happened.

In blockchains, transactions are bundled into a block and validated. Transactions that are not validated into blocks are simply pending transaction that has yet to happen. Therefore, from the protocol’s point of view, a flash loan is simply a special kind of loan where it is immediately return after borrowed. And in the event that the loan is not repaid, the earlier transaction that borrows the loan simply fails and does not get included in the block, which means the loan never took place!

However, flash loans does seem to have very little utility if it has to be repaid in a single transaction. Typical usage of flash loans is limited to moving liquidity such as arbitraging, collateral conversion, farm changing, etc. And in the case of profit opportunities, it will be even more limited as we are unlikely to see much price movement in a block duration. This is also the reason why flash loans are more popular on older blockchains that have longer block durations and deeper liquidity such as Ethereum.

Algorithmic Stablecoin Protocol

Stablecoin protocol is another important aspect to lending primitives. Similar to lending protocols, depositors deposit collateral into the protocol, and in exchange they get to mint stablecoins based on the amount of their deposits. In the event the amount of collateral falls below the circulating value of stablecoin, the protocols has to buy back & burn the stablecoins it has minted.

In the older models, stablecoins rely on arbitragers to maintain the stablecoin peg. Such examples are Terra, Acala, Maker where the peg hovers around $1 depending on the arbitragers. There are also variations such as Frax Finance and Ampleforth which takes on mixed approaches such as relying on other existing stablecoins and rebasing techniques.

This also led to invention of reserved currencies where the price of the asset is free floating despite the collateral backing underneath. The history, evolution & drama of reserved currencies is noted to be the most exciting events in the world of crypto and we will discuss it in detail in another article.

P2P loans

P2P loans protocol is essentially an inefficient application of non-custodial liquidity markets where the liquidity cannot be shared across borrowers and lenders. This can be beneficial when the assets is under-utilize where it would be more capital efficient for lenders to source higher interests. Although it would require effort to search for borrowers, lenders do not need to share their profits in the pooled liquidity.

With the rise of NFTs, P2P loans are becoming more popular as NFTs by itself is an illiquid asset. P2P loans allow NFT holders to hedge against their NFTs and bring liquidity to their assets.

NFTs are still in an infant phase at this stage and liquidity is still very fragmented. Hence, we would not be able to see well-defined APR at this point of time compared to mature lending markets.

Derivatives

With the existence of liquidation mechanism in lending primitives, it brings about the Cambrian explosion of financial derivatives. Margin trading, options, perpetuals, leveraged tokens all rely on the liquidation mechanism to achieve leverage, liquidation, funding and settlements.

Take for example auto-settlement of on-chain crypto options. During a call option expiry, the price of the underlying cryptocurrency will be compared against the strike price. If the strike price is lower than the price of the underlying asset, the option can be exercised automatically. A loan is first borrowed to exercised the option, upon receiving the underlying asset, the underlying asset is then sold and used to repay the loan. Any remaining excess will then be kept as profits for the option buyer.

There are of course also protocols that directly utilize the entire lending protocols to achieve leverage farming and all sorts of automated trading strategies.

For example, with leveraged lending we can achieve pretty high APR of over 100% on initial launch of the protocol in a new chain. While it is not sustainable in the long run, it is still pretty generous compared to existing lending protocols on mainstream Defi on Ethereum.

And with Defi & NFT space booming, we are bound to see more interesting derivatives becoming mainstream and the eventual phasing out of simple primitives.

Design of cosmwasm smart contracts

The architecture of cosmwasm smart contracts is very different from Solidity. Solidity is extremely easy to use and we can treat it without any considerations of blockchain architecture. To put it simply, the style of Solidity is OOP-style. We can adopt the same mindset of coding any object oriented language and treat smart contracts as classes/objects.

While there are indeed more advanced ways to structure your Solidity smart contracts, we will not discuss it as normal people don't do that anyways.

pragma solidity ^0.6.0;

interface IERC20 {
    function totalSupply() external view returns (uint256);
    function balanceOf(address account) external view returns (uint256);
    function allowance(address owner, address spender) external view returns (uint256);

    function transfer(address recipient, uint256 amount) external returns (bool);
    function approve(address spender, uint256 amount) external returns (bool);
    function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);


    event Transfer(address indexed from, address indexed to, uint256 value);
    event Approval(address indexed owner, address indexed spender, uint256 value);
}

cosmwasm is not. cosmwasm contract is split into 4 portions:

1. State (variables that you want to persist are defined here)

2. Query (query the state (variables) of the smart contract)

3. Execute (modify the state (variables) of the smart contract)

4. Instantiate (to initialized the smart contract) This leads to some inconvenience while coding, but also more flexibility & upgradeability of the smart contract. For example, developers need to manually call & access the state, unlike in Solidity where we can access it like an object.

pragma solidity ^0.6.0;

contract Example {
    uint256 amount;
    
    function getAmount() returns (uint256) {
        return amount;
    }
    ...
}

Solidity code

// Declare amount in state.rs
pub const AMOUNT: Item<i32> = Item::new("amount");

// Reading amount in query.rs
use crate::state::{AMOUNT}

pub fn get_amount(deps: DepsMut) --> StdResult<i32> {
    CONFIG.load(deps.storage)?
}

// Declare wrapper for query's logic in contract.rs
// Recall contract is split into state, execute, query, instantiate
use ...

pub fn query(deps: Deps, _env: Env, msg: QueryMsg) -> StdResult<Binary> {
    match msg {
        QueryMsg::GetAmount {} => to_binary(&get_amount(deps)?),
    }
}

// Declare message header in msg.rs
use ...

#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
#[serde(rename_all = "snake_case")]
pub enum QueryMsg {
    // GetCount returns the current count as a json-encoded number
    GetAmount {},
}

Rust Code (cosmwasm)

As you can see, in cosmwasm, there is a lot of organization and declaration that the developer needs to handle. In Solidity, this is all done automatically for the developer when they compile their code. However, it is worth noting that Solidity is specially designed and developed over a long time, allowing developers to enjoy the ease of coding today. Builders will continue building for cosmwasm and it is possible that these complexities can be abstracted one day.

Details

Terra's smart contract is split into several portions usually:

• contract.rs Entry point of the code

  • execute.rs Contract interaction that modifies the state (Cost gas fees)

  • query.rs Contract interaction that reads the state (Does not cost gas fees)

• error.rs Define your error codes

• lib.rs Linking your rust files

• test.rs QA's job

• state.rs Define your state, data you want to store in smart contracts

• msg.rs Define your method signature for contract interactions (execute, query, instantiate)

Top level

use ...

#[cfg_attr(not(feature = "library"), entry_point)]
pub fn instantiate(
    deps: DepsMut,
    _env: Env,
    info: MessageInfo,
    msg: InstantiateMsg,
) -> Result<Response, ContractError> {
    let state = State {
        count: msg.count,
        owner: info.sender.clone(),
    };
    set_contract_version(deps.storage, CONTRACT_NAME, CONTRACT_VERSION)?;
    STATE.save(deps.storage, &state)?;

    Ok(Response::new()
        .add_attribute("method", "instantiate")
        .add_attribute("owner", info.sender)
        .add_attribute("count", msg.count.to_string()))
}

#[cfg_attr(not(feature = "library"), entry_point)]
pub fn execute(
    deps: DepsMut,
    _env: Env,
    info: MessageInfo,
    msg: ExecuteMsg,
) -> Result<Response, ContractError> {
    match msg {
        ExecuteMsg::Increment {} => try_increment(deps),
        ExecuteMsg::Reset { count } => try_reset(deps, info, count),
    }
}

#[cfg_attr(not(feature = "library"), entry_point)]
pub fn query(deps: Deps, _env: Env, msg: QueryMsg) -> StdResult<Binary> {
    match msg {
        QueryMsg::GetCount {} => to_binary(&query_count(deps)?),
    }
}

contract.rs

In contract.rs we can see what functions we can call on the smart contract. In this example, we can perform get_count, increment, reset on the smart contract. And of course instantiate the smart contract.

use schemars::JsonSchema;
use serde::{Deserialize, Serialize};

#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
pub struct InstantiateMsg {
    pub count: i32,
}

#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
#[serde(rename_all = "snake_case")]
pub enum ExecuteMsg {
    Increment {},
    Reset { count: i32 },
}

#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
#[serde(rename_all = "snake_case")]
pub enum QueryMsg {
    // GetCount returns the current count as a json-encoded number
    GetCount {},
}

// We define a custom struct for each query response
#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
pub struct CountResponse {
    pub count: i32,
}

msg.rs

In msg.rs we declare the method signature of the smart contracts, which we will also be using to generate the schema to interact with the smart contract. So, for example, we want to call the reset function in the smart contract, we do something like the following when broadcasting the txn:

{
    "execute_msg": {
        "reset": {
            "count": 0
        }
    }
}

But in reality, when dealing with sdk or executing the txn from browser, we do not need to specify whether a transaction belongs to instantiation, execution or query as there are specific APIs in place for all different scenarios.

Core

use schemars::JsonSchema;
use serde::{Deserialize, Serialize};

use cosmwasm_std::Addr;
use cw_storage_plus::Item;

#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
pub struct State {
    pub count: i32,
    pub owner: Addr,
}

pub const STATE: Item<State> = Item::new("state");

state.rs

This is where you declare all the variables you want to have in the smart contracts. It will be used to store information that you want to persist in smart contracts. In the above example, we want to keep track of a variable called State with members count and owner which is of integer and address type respectively.

pub fn try_increment(deps: DepsMut) -> Result<Response, ContractError> {
    STATE.update(deps.storage, |mut state| -> Result<_, ContractError> {
        state.count += 1;
        Ok(state)
    })?;

    Ok(Response::new().add_attribute("method", "try_increment"))
}

pub fn try_reset(deps: DepsMut, info: MessageInfo, count: i32) -> Result<Response, ContractError> {
    STATE.update(deps.storage, |mut state| -> Result<_, ContractError> {
        if info.sender != state.owner {
            return Err(ContractError::Unauthorized {});
        }
        state.count = count;
        Ok(state)
    })?;
    Ok(Response::new().add_attribute("method", "reset"))
}

execute.rs

In execute.rs is where we finally get into coding the logic out! And this is just your typical rust coding with the exception of retrieving and persisting the state through using the deps variable.

fn query_count(deps: Deps) -> StdResult<CountResponse> {
    let state = STATE.load(deps.storage)?;
    Ok(CountResponse { count: state.count })
}

query.rs

query.rs is where we perform queries on various states about the smart contract. This is usually just getter functions unless we want something more complicated.

Fluff

use cosmwasm_std::StdError;
use thiserror::Error;

#[derive(Error, Debug)]
pub enum ContractError {
    #[error("{0}")]
    Std(#[from] StdError),

    #[error("Unauthorized")]
    Unauthorized {},
    // Add any other custom errors you like here.
    // Look at https://docs.rs/thiserror/1.0.21/thiserror/ for details.
}

error.rs

pub mod contract;
mod error;
pub mod msg;
pub mod state;

pub use crate::error::ContractError;

lib.rs

These are just fluff stuff we need to put. I don't think we need to talk much about this.

Automated market makers (AMM) are decentralized exchanges that pool liquidity from users and price the assets within the pool using algorithms. Initially, it begins with X * Y = K formula where K is a constant, X and Y are the 2 respective assets. When someone wants to trade Qx amount of token X for token Y, he/she will receive Qy tokens such that the following equation is satisfied: (X + Qx) * (Y - Qy) = K = X * Y.

The paper can be found here.

However, AMM has evolved drastically over time. Basically, AMMs today are partitioned into smaller pools so that they can maximize trading fees and minimize potential losses. And there are a variety of strategies employed to design these AMMs such as Uniswap V3, Balancer, Curve.

Then came decentralized orderbooks which employ traditional strategies as today's market makers. The liquidity required for the orderbook can also be provided by AMMs such as the Serum orderbook on Solana. This is much more difficult to design as a smart contract compared to traditional AMMs due to limitation of blocktime and gas fees, especially on older blockchains like Ethereum, Polygon, Binance chain etc.

Trading in Modern Defi

Today, traders no longer use Decentralized Exchanges as it is. Users of Defi today use aggregators to perform their trades on-chain. For example, on Ethereum, users use Cowswap to perform their trades. Cowswap is an adoption of Gnosis Protocol v2 which offers trading with MEV protection on top of aggregation across both AMMs and traders.

This is achieved through the following:

1. Transactions are first submitted and auction separately from the Ethereum chain.

2. If there are matching orders amongst the transactions, they can be matched directly. Remaining liquidity can be bundled and then trade against all the existing AMMs to ensure the best price possible.

This prevents a myriad of issues. Sandwiching attack is not possible on these trades as transactions are not visible in the mempool and submitted in a bundle by the solvers. Gas fees can also be amortized across the trades and users need not pay transaction fees if the transaction does not go through (transactions are submitted to solvers as opposed to Ethereum nodes). How each individual AMMs/Orderbook works will not matter as it will simply pick the best price for the traders. And this does leads to an interesting result, AMMs/Orderbook liquidity optimization no longer matters, isolated DEX that can offer the best price will get the profits (provided they are not making a loss).

Oracle driven AMMs

Newer models of AMMs on high performing blockchains today employ different strategies to maximize yield & performance. AMMs today explore options on following oracle prices as opposed to relying on market forces to stabilize their price. While liquidity management within the AMM is still important to ensure that the pool doesn't lose money/have sufficient funds during volatility, the focus here is to provide the most competitive price (and also possibly perform the arbitrage themselves). This is evident within Solana ecosystem as there are performant enough oracles like Pyth Network which is able to fetch/aggregate the trading price of other cryptocurrencies fast enough from various data sources.

Examples of such AMMs are Lifinity and DeltaFi, especially Lifinity which dominates all other AMMs during aggregation when dealing with trading small amounts of liquidity. But their depth of liquidity is still small and larger trades will still involve the early market leading DEX-es.

Beyond Single Chain

As more blockchains begin to have their own ecosystem, cross-chain swaps become a topic to explore. There are several existing cross-chain DEX-es that truly facilitate swaps (not Sushiswap kind of cross-chain where the DEX is available on different chains, but you still cannot cross those assets) across different chains such as Stargate and Thorchain. These are blockchains that enables swap between different blockchains/networks directly without dealing with bridges and their associated fees.

This can be achieved through an intermediary exchange of asset to their native token and back to the target asset. You can read more here.

Active Liquidity

Moving on, DEX-es today still do not fully utilize their liquidity well enough. Most DEX-es still use dual asset liquidity pools regardless of how much they optimize themselves. In reality, the same asset can be used to provision for multiple liquidity pools and earning trading fees from all of that. Such an example is Balancer in which liquidity is provided as a single asset, and then provision as modules to various pools such as the traditional dual-token liquidity pools or stablecoin pools. However, in this model, liquidity is ultimately still not shared amongst the different pools and depositors cannot truly maximize their gains.

Compossable Finance offers another model known as just-in-time liquidity, where liquidity is provision only during the time of the swap. After the swap, the liquidity is removed and returned to the provider. There are people who have attempted this concept on existing AMM like Uniswap V3 and could be very well profitable. Active liquidity allows the user to not only provision liquidity for multiple DEX-es simultaneously, it also allows user to provision liquidity for multiple assets at the same time. Of course, this is accompanied by the risk where the impermanent loss is amplified across the different pools (but of course this can be mitigated by only providing liquidity to only stablecoin pairs or when the trade favors the stablecoin asset).

And rewards can be further optimized by trading with derivative assets that compound yield such as liquid staking, vault shares or even sOhm derivatives if you are feeling degenerate.