In this lesson, you will:
Composability in Web3 is akin to the use of open-source software components in building diverse applications. In Solana, it resembles Functional Programming (FP), while Ethereum’s approach is more akin to Interface-based Inheritance in Object-Oriented Programming (OOP). Solana centralizes token management via spl-token, whereas Ethereum employs separate contracts like ERC-20 for each token type.
Composability allows blockchain applications to collaborate effectively, linking through smart contracts or project assemblies. It offers faster development, spurs innovation, and facilitates user-friendly interactions in the Web3 space.
Composability, a familiar concept for Web2 developers, involves using modular software components adaptable to various applications. This principle, rooted in open-source technology, has been pivotal since the early internet days, boosting both Web2 and now Web3, enhancing user experiences and fostering new ideas.
Web3, the evolved iteration of the internet, re-emphasizes composability. In this context, composability happens when blockchain applications, such as trading platforms and decentralized apps (DApps), interconnect through smart contracts or project assemblies.
Of Programs
In Solana, composability can be likened to Functional Programming (FP). This approach involves distinct roles for smart contracts and the data they utilize. Transactions in Solana revolve around Solana accounts, which form the cornerstone of the ecosystem. Unlike Ethereum, where each token operates through its unique contract, Solana employs spl-token to manage all tokens centrally.
Conversely, Ethereum's composability echoes interface-based inheritance found in traditional Object-Oriented Programming (OOP). This means treating entities according to their behaviour. Ethereum builds upon established standards like ERC-20, requiring specific function implementations.
In Ethereum, data resides directly within smart contracts, whereas Solana distributes data across numerous atomic accounts. While this may seem complex, it allows Solana to execute multiple operations concurrently. Transactions that only read from an account without altering it can be processed simultaneously.
In Solana's programming environment, different programs communicate via Cross-Program Invocation (CPI) and Program-Derived Addresses (PDA). This enables one program to instruct another, pausing while the second program executes the task.
Here's a simplified comparison between Solana and Ethereum composability:
Aspect | Solana | Ethereum |
---|---|---|
Composability Approach | Functional Programming (FP) | Interface-based Inheritance (OOP) |
Token Management | Centralized via spl-token | Individual contracts (e.g., ERC-20) |
Transaction Foundation | Centered around Solana accounts | Focused on smart contract interactions |
Data Storage | Data distributed across atomic accounts | Data stored within the smart contract |
Concurrency Advantage | Supports simultaneous task execution | Limited parallel processing |
Inter-Program Communication | Cross-Program Invocation (CPI) and PDA | Interfaces and inheritance |
Cross-Program Invocation (CPI) is a crucial element in enabling collaboration between Solana programs. It facilitates the composability of these programs, allowing one to call another, thereby creating a seamless network. This feature simplifies the expansive ecosystem, unifying it for developers.
Implementing CPI Calls
In CPI, a program calls another, targeting a specific instruction within that program. CPIs allow the calling program to extend its signer privileges to the callee program. This is accomplished using methods like invoke
or invoke_signed
, the latter being used when signatures are required for Program-Derived Addresses (PDAs).
CPIs are instrumental in interlinking Solana programs. Any public instruction of a program can be invoked by another through CPI, ensuring harmonious operation within the ecosystem. While the accounts and data sent to a program are not directly controllable, it's vital to thoroughly verify the information passed into a CPI for security and functionality.
The process of one program calling another is straightforward when viewed as issuing an "Instruction." To execute a CPI, you must define and construct an instruction on the invoked program and provide a list of necessary accounts. If a PDA is involved as a signer, signers_seeds
must also be included in invoke_signed
.
An Instruction requires three key elements: the program ID of the called program, data the program can interpret, and a list of "AccountInfos." These AccountInfos represent the accounts the called program will utilize.
The calling program receives these AccountInfos from the system at the outset. Thus, any account needed by the called program must also be required by the calling program, creating a chain of dependencies.
In this tutorial, you'll learn how to use invoke
CPI in Solang when a Program-Derived Address (PDA) is not required as a signer.
APIs, serving as modular building blocks for application development. Projects like Uniswap, a decentralized exchange, provide ready-made smart contracts that can simplify tasks in other applications.
How Composability Works in Ethereum Ethereum's smart contracts are universally accessible, promoting application development with their open nature. Composability in Ethereum is built on three key pillars:
Here's an example to illustrate:
Consider a scenario where the price of a token differs between two exchanges. If you possess sufficient funds, you could purchase the token at a lower price on one exchange and sell it at a higher rate on another, securing a profit. In case of inadequate funds, a flash loan comes into play. This type of loan allows you to borrow assets without collateral. By leveraging flash loans, you can execute complex transactions, like simultaneous buying and selling, to capitalize on market discrepancies—all enabled by the collaborative nature of smart contracts.
Advantages of Composability:
In our next lesson, we will dive into coding the CPI Flip program.