DEV Community: esteblock

Fullstack Blockchain Job Offer

esteblock — Mon, 05 Aug 2024 23:12:09 +0000

Full-time Position (Internships also accepted)

🧑‍💻 𝗝𝗼𝗶𝗻 𝗣𝗮𝗹𝘁𝗮𝗹𝗮𝗯𝘀 𝗮𝗻𝗱 𝗯𝗲 𝗽𝗮𝗿𝘁 𝗼𝗳 𝘁𝗵𝗲 𝗕𝗹𝗼𝗰𝗸𝗰𝗵𝗮𝗶𝗻 𝗿𝗲𝘃𝗼𝗹𝘂𝘁𝗶𝗼𝗻!

🥑 𝗣𝗮𝗹𝘁𝗮𝗹𝗮𝗯𝘀 excels in:

dApp Creation: Innovative decentralized applications.
Blockchain Consulting: Expert guidance in integration.
Continuous Learning: Deep knowledge in Blockchain.

What have we done? We created the first Decentralized Exchange with Smart Contracts on the Stellar Blockchain. See Soroswap.Finance Webpage | Soroswap Github. We also have another DeFi investment project and are constantly creating tools for developers. Additionally, we are creating content and educating.

Learn more on our LinkedIn, Twitter/X, Website, and Github.

📝 Benefits of joining us:

🤑 Intern Salary USD 500-1200
🤑 Professional Salary USD 1200-3500
🌍 Remote Work: Flexibility to work from anywhere.
🕒 Flexible Hours: Adapt your schedule.
🏋️‍♀️ Activity Bonus: Stay active with incentives.
🌴 24 Vacation Days: Generous time off.
🤓 Learning Environment: Support and collaboration.

🔍 𝗪𝗵𝗮𝘁 𝘆𝗼𝘂 𝘄𝗶𝗹𝗹 𝗱𝗼:

📱 dApp Development: Build decentralized applications.
🤖 Bot Construction: Design automation bots.
📝 Script Development: Create functional scripts.

🔧 𝗥𝗲𝗾𝘂𝗶𝗿𝗲𝗱 𝗧𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝗦𝗸𝗶𝗹𝗹𝘀:

🧠🔗 Blockchain Knowledge: Understand how a Blockchain works.
🖥️💼 Backend Proficiency: Competence in backend languages like Python, Typescript, or Javascript.
🌐⚛️ Frontend with React: Skill in frontend development using React.
📂🔄 Version Control with Git: Mastery of Git for version control.

🧠 𝗥𝗲𝗾𝘂𝗶𝗿𝗲𝗱 𝗦𝗼𝗳𝘁 𝗦𝗸𝗶𝗹𝗹𝘀:

⏳📅 Time Management: Ability to manage your time well.
🧘‍♂️😌 Stress Management: Ability to work under pressure and handle stress.
🎯🔍 Focus: Great ability to concentrate and pay attention to detail.
💬📖 Communication: Fluent in Spanish and proficient in reading and writing in English.
🌟🚀 Motivation for Web3: Highly motivated and enthusiastic about working in the Web3 ecosystem.

✨ 𝗗𝗲𝘀𝗶𝗿𝗲𝗱 𝗦𝗸𝗶𝗹𝗹𝘀 (𝗡𝗼𝘁 𝗥𝗲𝗾𝘂𝗶𝗿𝗲𝗱):

💻🔐 Smart Contract Development: Experience writing Smart Contracts in Solidity or Rust.
🪐⭐ Knowledge of Stellar and Soroban.
🧪✔️ Testing Frameworks Knowledge: Familiarity with testing frameworks.
🌍🔧 Open Source Contributions: Experience contributing to open source projects.
📁🌟 GitHub Portfolio: Demonstrable projects or courses on GitHub.
🎨🎸 Hobbies: We value work-life balance and diverse interests.

📋 𝗛𝗼𝘄 𝘁𝗼 𝗔𝗽𝗽𝗹𝘆:
1.- Review the offer in detail and complete the form at https://tally.so/r/mBZze4

2.- Join our Discord and check out the challenge we have for you in #technical-challenge. Join here: https://discord.gg/5sAHXCr4dV

It is very important that in addition to filling out the form, you complete the challenge. If you have questions, ask in #technical-challenge and we will respond.

We look forward to your application!

Oferta de Trabajo Fullstack Blockchain

esteblock — Mon, 05 Aug 2024 22:10:16 +0000

Puesto Full-time (También aceptamos prácticas)

🧑‍💻 𝗨́𝗻𝗲𝘁𝗲 𝗮 𝗣𝗮𝗹𝘁𝗮𝗹𝗮𝗯𝘀 𝘆 𝘀𝗲 𝗽𝗮𝗿𝘁𝗲 𝗱𝗲 𝗹𝗮 𝗿𝗲𝘃𝗼𝗹𝘂𝗰𝗶𝗼́𝗻 𝗱𝗲𝗹 𝗕𝗹𝗼𝗰𝗸𝗰𝗵𝗮𝗶𝗻!

🥑 𝗣𝗮𝗹𝘁𝗮𝗹𝗮𝗯𝘀 se destaca en:

Creación de dApp: Aplicaciones descentralizadas innovadoras.
Consultoría Blockchain: Orientación experta en integración.
Aprendizaje Continuo: Profundos conocimientos en Blockchain.

Que hemos hecho? Creamos el primer Exchange Descentralizado con Smart Contracts en la Blockchain de Stellar Soroswap.Finance Webpage | Soroswap Github. También tenemos otro proyecto de inversión DeFi yestamos constantemente creando herramientas para desarrolladores. También estamos creando contenido y educando.

Consulta más en nuestro Linkedin, Twitter/X, Sitio Web y Github

📝 Beneficios de unirse a nosotros:

🤑 Salario Practicante USD 500-1200
🤑 Salario Profesional USD 1200-3500
🌍 Trabajo Remoto: Flexibilidad para trabajar desde cualquier lugar.
🕒 Horarios Flexibles: Adapta tu horario.
🏋️‍♀️ Bono de Actividad: Mantente activo con incentivos.
🌴 24 Días de Vacaciones: Generoso tiempo libre.
🤓 Entorno de Aprendizaje: Apoyo y colaboración.

🔍 𝗤𝘂𝗲 𝗵𝗮𝗿𝗮́𝘀:

📱 Desarrollo de dApp: Construir aplicaciones descentralizadas.
🤖 Construcción de Bots: Diseñar bots de automatización.
📝 Desarrollo de Scripts: Crear scripts funcionales.

🔧 𝗛𝗮𝗯𝗶𝗹𝗶𝗱𝗮𝗱𝗲𝘀 𝗧𝗲́𝗰𝗻𝗶𝗰𝗮𝘀 𝗥𝗲𝗾𝘂𝗲𝗿𝗶𝗱𝗮𝘀:

🧠🔗 Conocimiento de Blockchain: Comprender cómo funciona una Blockchain.
🖥️💼 Dominio de Backend: Competencia en lenguajes de backend como Python, Typescript, o Javascript.
🌐⚛️ Frontend con React: Habilidad en desarrollo frontend utilizando React.
📂🔄 Gestión de Versiones con Git: Dominio de Git para control de versiones.

🧠 𝗛𝗮𝗯𝗶𝗹𝗶𝗱𝗮𝗱𝗲𝘀 𝗕𝗹𝗮𝗻𝗱𝗮𝘀 𝗥𝗲𝗾𝘂𝗲𝗿𝗶𝗱𝗮𝘀:

⏳📅 Gestión del Tiempo: Capacidad para manejar bien su tiempo.
🧘‍♂️😌 Manejo del Estrés: Habilidad para trabajar bajo presión y manejar el estrés.
🎯🔍 Concentración: Gran capacidad de concentración y atención al detalle.
💬📖 Comunicación: Hablar español y tener habilidades de lectura y escritura en inglés.
🌟🚀 Motivación para Web3: Estar muy motivado y entusiasta por trabajar en el ecosistema Web3.

✨ 𝗛𝗮𝗯𝗶𝗹𝗶𝗱𝗮𝗱𝗲𝘀 𝗗𝗲𝘀𝗲𝗮𝗯𝗹𝗲𝘀 (𝗡𝗼 𝗥𝗲𝗾𝘂𝗶𝘀𝗶𝘁𝗼𝘀):

💻🔐 Desarrollo de Smart Contracts: Experiencia en escribir Smart Contracts en Solidity o Rust.
🪐⭐ Conocimiento de Stellar y Soroban.
🧪✔️ Conocimiento de Frameworks de Testing: Familiaridad con frameworks de testing.
🌍🔧 Contribuciones a Proyectos Open Source: Experiencia en contribuciones a proyectos de código abierto.
📁🌟 Portafolio en GitHub: Tener proyectos o cursos demostrables en GitHub.
🎨🎸 Tener Hobbies: Valorizamos el balance vida-trabajo y la diversidad de intereses.

📋 𝗖𝗼́𝗺𝗼 𝗣𝗼𝘀𝘁𝘂𝗹𝗮𝗿:
1.- Revisa la oferta en detalle y completa el formulario en https://tally.so/r/mBZze4

2.- Únete a nuestro Discord y revisa en #tecnical-challenge el desafío que tenemos para ti. Untete aqui: https://discord.gg/5sAHXCr4dV

Es muy importante que además de llenar el formulario, hagas el desafío. Si tienes dudas, pregunta en #tecnical-challenge y te responderemos.

¡Esperamos tu postulación!

Costs, DoS Risks, and Instance vs Persistent Data Types in Soroban

esteblock — Fri, 19 Jan 2024 19:45:30 +0000

In the development journey of the Soroswap.Finance protocol, critical decisions regarding data types for Smart Contracts were made. The choice of storage impacts the risk of Denial of Service (DoS), increases contract interaction costs, or introduces both risks simultaneously.

This article explores the advantages and drawbacks of four design patterns for storing an increasing amount of information on the Soroban blockchain. Additionally, it delves into the associated costs for each scenario.

Context: Soroswap.Finance is an Automated Market Maker in the Soroban Smart Contract Platform within the Stellar Blockchain, developed by the PaltaLabs 🥑 team.

Follow the code here: Instance-Persistent-Dos-Soroban

TLDR;

This article demonstrates that:

Instance data types share a common Ledger Entry, leading to contract failure if the total stored information reaches 64kb.
Instance storage Ledger Entry is independent of contract size, with a fixed 64kb reserved regardless of contract dimensions.
Instance data types are read on every interaction, making any contract interaction more costly.
Unbounded data storage in Vectors or Mappings risks reaching 64kb and becoming vulnerable to DoS attacks.
The variable DataKey technique is the recommended approach for storing unbounded data.

Instance and Persistent Data Types.

From Soroban documentation, we know that:

Instance storage has its data limit determined by the ledger entry size (Source).
All instance storage is kept in a single contract instance LedgerEntry with a 64kb size (Source).
The Ledger Entry Size is capped at 64kb (Source).

The Challenge: Store Unbounded Information

The example challenge involves creating a Smart Contract that stores two collections of an increasing amount of 32-byte addresses, representing buyers and sellers. Two separate collections are used, as the choice of data type can impact one collection when the other grows.

Externally, interactions with this contract are intended to follow this pattern for each collection:

Call a function to store a new address (number n).
Retrieve the address for a given number n.

Indeed, tests for each design are the same, and they all pass! So be aware dev, passing your test does not means that your code is safe!

In the following sections, four design patterns will be explained, with only one proving to be DoS-free and not increasing the cost of interacting with the contract.

Design 1: Store a Vector in an Instance Data Type. The Case of a Light Smart Contract.

With this technique, a vector is stored in an instance storage slot. Each time a new element is pushed, the current vector value is read, the new element is added, and the updated vector is written back to the same instance storage slot. The code looks like this:

let mut vector: Vec<Address> = env.storage().instance()
            .get(&VECTOR_A).unwrap_or(Vec::new(&env)); // If no value set, assume an empty vector.

// Push the current contract address in the vector
vector.push_back(env.current_contract_address().clone());

// Save the updated vector to instance storage
env.storage().instance().set(&VECTOR_A, &vector);

A DoS attack simulation reveals that this design causes the contract to fail with a ResourceLimitExceeded error after the sum of the collections reaches 64kb, equivalent to 818 pushes of addresses on each collection. Further details, including code, simulation, and results, can be found in the repository. Additionally, this design increases the cost of every call to the smart contract, even for unrelated functions.

Design 2: Store a Vector in an Instance Data Type.. The Case of a Heavy Smart Contract.

Similar to Design 1, this approach demonstrates that instance storage is stored in an independent LedgerEntry from the Smart Contract itself. With this design, the cost of reading the contract increases with every push operation, even for unrelated functions. This design also results in a ResourceLimitExceeded error.

Design 3: Store a Vector in a Persistent Data Type..

This design involves storing a vector in a persistent data type.

let mut vector: Vec<Address> = env.storage().persistent()
            .get(&VECTOR_A).unwrap_or(Vec::new(&env)); // If no value set, assume an empty vector.
vector.push_back(env.current_contract_address().clone());
env.storage().persistent().set(&VECTOR_A, &vector);

While it avoids sharing storage size with other variables, it is still limited to 64kb of information. Details of an attack simulation show that it allows reaching twice the number of entries compared to the previous examples. However, the cost of reading the contract does not increase for unrelated functions, as persistent data type is not retrieved every time the contract is called.

Design 4: Use Variable DataKeys with Persistent Data Type..

This design introduces the Variable DataKey technique, where the name of the storage slot depends on a parameter. The DataKey is defined as follows:

#[contracttype]
pub enum DataKey {
    StoredAddressesA(u32),
}

This technique is commonly used to store an increasing amount of data, as seen in the token contract for storing user balances. The information is stored as follows:

let mut count: u32 = env.storage().instance().get(&COUNTER_A).unwrap_or(0); 
env.storage().persistent().set(&DataKey::StoredAddressesA(count), &env.current_contract_address().clone());
count += 1;
env.storage().persistent().set(&COUNTER_A, &count);

This design, including the storage of a COUNTER to track the number of stored addresses, is considered the best option. It successfully avoids DoS attacks and minimizes the cost of reading the contract.

Using u32 provides 2^32 different storage slots for StoredAddressA, which is more than sufficient. Even if an attacker were to call the push function 2^32 times, the associated cost is calculated to be around 439,289 stroops (0.044 XLM). This cost limitation makes it practically infeasible for an attacker, even with the entire Total Supply of XLM (50,001,787,051), to add more than 2,196,523,503 entries (2^21).

Design 5: Use Variable DataKeys with Instance Data Type.

Lastly, using Variable DataKeys as a solution with instance data type is a mistake. This design is as inefficient as using a vector because storing in different slots shared in a single Ledger Entry is almost equivalent to storing everything in one slot, similar to a vector. This situation can lead to a DoS attack and result in a ResourceLimitExceeded error.

Contact us:

Did you like the article? Contact us in our Discord https://discord.gg/HFkBquZNNg or reach us in https://paltalabs.io

Managing different Soroban CLI versions

esteblock — Tue, 26 Dec 2023 13:08:14 +0000

Sometimes you might want to manage different soroban CLI versions, in order to work with different projects in your computer.

Or maybe, sometimes there is a last minute upgrade you want to try, but you don't want to change your computer's configuration.

How can we solve this?

The Soroban Preview Docker Image

The soroban-preview-docker images are Docker images with the 4 main necessary configurations in order to run soroban CLI: 1) An Ubuntu Linux manchine 2) Rust & Cargo installed, 3) Node installed, and 4) The desired soroban CLI version.

You can check how this images are built, by checking this esteblock/soroban-preview:20.1.0 Dockerfile

How to use this together with a Quickstart Image node?

Check how we do it in Soroswap: We have 3 files:

1.- The preview_version.json file, where we fix both the quickstart and the soroban-preview docker images versions

2.- The quickstart.sh bash script that Creates a common docker network and opens both Docker containers.

3.- The run.sh bash script that helps us open the desired (and already running) soroban preview docker container

Run the Containers:

bash scripts/quickstart.sh
bash scripts/run.sh

Do it your self.

1) Create a common Docker Network, so both Docker containers (Stellar Quickstart & Soroban Preview) can talk to each other

docker network create soroban-network

2) Open a Docker Container with the Soroban Preview Docker image

docker run -dti \
  --volume ${currentDir}:/workspace \
  --name soroban-preview-${previewVersion} \
  -p 8001:8000 \
  --ipc=host \
  --network soroban-network \
  esteblock/soroban-preview:${previewVersion}

3) Open a Stellar Quickstart Docker Container

# Run the stellar quickstart image
docker run --rm -ti \
  --name stellar \
  --network soroban-network \
  -p 8000:8000 \
  stellar/quickstart:${quickstartHash} \
  $ARGS \
  --enable-soroban-rpc \
  --protocol-version 20 \
  --enable-soroban-diagnostic-events \
  "$@" # Pass through args from the CLI

Installing Freighter

esteblock — Wed, 15 Nov 2023 22:16:32 +0000

1. Installing Freighter

In this section, we will guide you through the installation process of Freighter, a non-custodial Stellar wallet extension that will empower you to engage with Soroswap.Finance

Step 1: Installing Freighter on your Browser

Freighter works as a Extension in Chrome (Google Chrome, Brave) and Firefox:

Visit the Freighter Official Website, to install Freighter into your browser.
Click on "Create Account" and choose a secure password.

Step 2: Safeguarding Your Wallet

Upon creating your account, you will be presented with a secret recovery phrase. This phrase acts as a backup for your wallet's private key, allowing you to restore your wallet in case of loss, theft, or device damage.

Follow these important guidelines to protect your funds:

Save the Seed Phrase: Keep your seed phrase in a safe place. Treat it as a valuable key to your funds and store it confidentially.
Secure Storage: Store the seed phrase in a secure location, such as a locked drawer or a password-protected digital storage solution. Ensure it is shielded from unauthorized access and potential loss.
Exercise Caution: Remember, anyone with access to your seed phrase can gain control over your wallet and its contents. Take the necessary precautions to safeguard it diligently.

Step 3: Confirming Your Seed Phrase

To ensure accuracy, you will be asked to confirm your seed phrase in the same order. This step guarantees that you have correctly noted down your recovery phrase.

Step 4: Accessing Your Wallet

Congratulations! You are now ready to use your Freighter wallet. Follow these final steps:

Open the Freighter extension in your browser.

Your account will be displayed, labeled as "Account 1," along with your unique account address. This address serves as an identifier for receiving funds or transactions from other users or entities on the blockchain network.
Click on the "Main Net" button located at the top right corner to explore the networks:

Mainnet: The live and fully operational blockchain network where real transactions occur.
Testnet: A simulated environment for testing and experimentation

Since Soroswap is currently in the Soroban Testnet environment, we will proceed with the tutorial using the Testnet setting. By utilizing the testnet, we can safely explore and demonstrate the functionalities of Soroswap without any concerns about real-world financial implications.

Step 5: Let's Dive into the Tutorial

Congratulations! You are now fully equipped to embark on an exciting journey with Soroswap on the testnet. Get ready to explore and make the most of Soroswap's comprehensive range of features within this secure testing environment. Let's dive right into the tutorial and unlock the full potential of your Soroswap experience!

Soroswap 🪐 on Testnet Overview

esteblock — Wed, 15 Nov 2023 20:53:15 +0000

Soroswap Testnet Overview

Soroswap is an Automated Market Maker (AMM) built on Soroban, designed to facilitate token trading and liquidity provision. With its user-friendly interface, Soroswap offers a seamless and intuitive experience for users to engage with decentralized finance (DeFi) on the Soroban and Stellar

Check it in https://soroswap.finance/

User-Friendly Interface

Soroswap boasts a user-friendly interface that ensures a smooth and enjoyable trading experience. The intuitive design caters to both beginners and experienced traders, making it easy to navigate the platform and interact with its features.

Key Features and Benefits

** Currently Soroswap works only on Soroban Testnet**, and provides several key features and benefits for users:

Balance Section: Conveniently view your test token balances in the Balance section. This feature allows you to keep track of your assets and monitor their availability for transactions within the app.
Swap Section: Easily exchange one token for another within the liquidity pool using Soroswap's Swap section. This feature provides a straightforward and efficient solution for diversifying your portfolio or making specific token swaps.
Liquidity Section: Empowers users to add or remove liquidity from the pools. By participating in liquidity provision, you contribute to the stability and efficiency of the Soroswap ecosystem. Effectively manage your liquidity positions in the Liquidity section for a smooth and rewarding experience.

Soroswap on the Sorosban Testnet allows users to fully explore and test the platform using test tokens. This enables you to experience the complete functionality of the app without risking real funds. It provides an opportunity to familiarize yourself with the features, understand the process of adding liquidity, performing swaps, and removing liquidity.

By utilizing Soroswap on the testnet, you can gain hands-on experience with decentralized exchanges and DeFi concepts. It serves as a valuable learning tool and a safe environment to experiment with different trading strategies and liquidity provision.

In the following sections, we will provide step-by-step instructions on how to use Soroswap on the testnet, including installing the Freighter wallet, adding liquidity, performing swaps, and removing liquidity. These instructions will help you navigate the platform and make the most of the features and benefits offered by Soroswap. Let's dive in!

Did you like it?
Please give us feedback. Join our Discord channel: https://discord.gg/wyesAQhP

Soroswap.Finance 🪐 is live on Soroban Testnet ✨!

esteblock — Wed, 15 Nov 2023 20:50:39 +0000

Soroswap.Finance 🪐 is now live on Soroban Testnet, and we couldn't be more thrilled to share this exciting news with the Stellar and Soroban communities!

Ten months have passed since Soroswap proudly clinched the 3rd prize in the inaugural Hacka-Soroban-athon 🖥, Soroban's first-ever hackathon. Our journey has been filled with dedication, a evoluting team of over 10 talented collaborators, collaboration with an external design agency, and participation in key events like the sub0 Polkadot 🧬 Conference and the Meridian 2023 conference in Madrid 🇪🇸.

Soroswap is an open-source AMM protocol designed to enhance liquidity provision and asset trading for Stellar assets within the Soroban ecosystem. It comes equipped with an SDK and a user-friendly frontend to make your experience seamless.
Soroban is the new Smart Contract platform of the Blockchain Stellar, and we are creating DeFi primitives on it!

Experience Soroswap on Testnet now!: https://soroswap.finance/

To get started, simply access it with a Freighter Wallet version 5.6.4 or higher. On our Testnet dapp, you can experiment with our test tokens and get a feel for the platform. Mint test tokens, provide liquidity and do swaps"

Your Feedback Matters 💭: We welcome your valuable feedback! Your input is crucial to us and the entire ecosystem. If you have questions, find bugs, or just want to share your thoughts, please don't hesitate to reach out. We're eager to incorporate your insights into this incredible project. You can do this by:

What is next? 🥑✨
For the final months and 2024 Q1 Soroswap.Finance Rodamap looks like this:

Implement Mercury 🌐 Indexer to become a multi AMM Aggregator
Implement Mercury 🌐 Indexer for a Enhanced Dashboard
Implement Mercury 🌐 Indexer for a Optimal Routing
Implement a Bridge (AllBridge in/to Ethereum or Pendulum in/to Polkadot!)
Community Building

We still have a lot of things to build!
We hope you give us your support to let this happen!

A Big Thank You 🤗: We owe a massive thanks to the Stellar Community Fund (SCF) for making this journey possible. You can review all our SCF deliverables in our SCF tracker repo.

Meet the Team 🧑‍🤝‍🧑:
Soroswap.Finance 🪐 is brought to you by PaltaLabs🥑, a dynamic Blockchain Development Laboratory with contributors from Santiago, Valdivia and Rancagua (Chile), Rio de Janeiro (Brazil), Berlin (Germany), and Arras (France). Our team is a blend of dedicated full-timers, part-timers, and past collaborators who may rejoin us in the future. We extend our heartfelt gratitude to everyone who's played a role in Soroswap's journey.

Esteban Iglesias (esteblock), CEO & Founder, Fullstack Blockchain Developer
Francisco Catrileo (devmonsterblock), Fullstack Blockchain Developer
Joaquín Soza (yripper), Fullstack Blockchain Developer
Maximiliano Carrasco (abstract#1547), Frontend Developer
Viviana Manríquez (vivitapatita), Brand Coordinator
Diego Correa Tristain (diegotristain), Rust Developer
Benjamin Salon(benjaminsalon) Computer Science & @soroban-react Supporter
Jose Tomas Schuwirth (ealric), Frontend Web3 Developer
Mauricio Patiño (.maur0), Full-Stack Developer
Ricardo Rodriguez (ricardor4), Computer Science & Mathematics Models
José Fredes (draken1700), Frontend Developer

Join us in exploring Soroswap on Testnet and help us make it even better! Your involvement is key to the success of this innovative project. 🚀🌟

Welcome to Soroswap.Finance

esteblock — Tue, 31 Oct 2023 12:29:51 +0000

This will be our space to share what we are building in the Soroban / Stellar Blockchain!

https://soroswap.finance/

Converting a Soroban Smart Contract into a crate library

esteblock — Tue, 17 Oct 2023 16:56:12 +0000

I am working developing Soroswap.Finance, an AMM in Soroban and we write our Smart Contracts based on the UniswapV2 Smart Contracts written in Solidity.

In Solidity we can write an smart contract, deploy it and use it as an smart contract and also use the same code as a library, so another smart contract can inherit its logic.

Common usage is:

contract MyContract is ContractFather

Another usage is to use a Solidity library like:

import './libraries/UniswapV2Library.sol';

...
// and then use the library like:
uint amountBOptimal = UniswapV2Library.quote(amountADesired, reserveA, reserveB);

How can we do something similar with rust and soroban-sdk?

The Library Contract

I wrote the SoroswapLibrary Smart Contract and it was working perfectly: Here is the code I had at the moment:
https://github.com/soroswap/core/tree/c65cebcfe69f05b38567158610dab25a941d4e6a/contracts/library

Publishing into crates.io

In order to transform this "pure" Smart Contract into a Library that can be imported by another Smart Contract I did the following:

1.- Edit the Cargo.toml to add some information necessary to publish into crates.io

[package]
name = "soroswap-library"
version = "0.1.1"
description = "Library that enables efficient and optimized code execution across different contracts on the Soroswap.Finance protocol"
homepage = "https://github.com/soroswap/core/tree/main/contracts/library"
repository = "https://github.com/soroswap/core/tree/main/contracts/library"
authors = ["esteblock <esteblock@paltalabs.io>"]
readme = "README.md"
license = "GPL-3.0"
edition = "2021"
keywords = ["no_std", "wasm", "soroswap", "amm", "soroban"]
rust-version = "1.73"
publish = true

2.- Create an account in crates.io and login

cargo login

3.- Publish:

cargo publish

If everything goes well, your contract will be published in crates.io and you can use it

Importing it into your code:

In my Router contract I can use it as a library, editing Cargo.toml

[dependencies]
soroban-sdk = { version = "20.0.0-rc2" }
num-integer = { version = "0.1.45", default-features = false, features = ["i128"] }
soroswap-library = "0.1.1"

And I should be able to use it inside my lib.rs as

use soroswap_library;

The "no external crate" error

When I complile the Router contract I had the following error:

error[E0432]: unresolved import `soroswap_library`
 --> src/lib.rs:9:5
  |
9 | use soroswap_library;
  |     ^^^^^^^^^^^^^^^^ no external crate `soroswap_library`

Very strange... But I found that I could solve it, adding the rlib crate type in the library contract... So it stays like this:


[lib]
crate-type = ["cdylib", "rlib"]

Moving out your desired functions.

Also, in order to use a function as a crate library, you'll need to move them out from the contract Trait... and re-export them:

In my case, the Library's lib.rs has:

mod test;
mod tokens;
mod reserves;
mod quotes;

pub use tokens::{
    sort_tokens,
    pair_for
};
pub use reserves::{
    get_reserves
};
pub use quotes::{
    quote, 
    get_amount_out, 
    get_amount_in, 
    get_amounts_out, 
    get_amounts_in
};

Check the final code here: https://github.com/soroswap/core/tree/main/contracts/library

Using the library

With this change (and of course after publishing a new version of the library in crates.io), I could use in my Router

use soroswap_library;
// and then

let amount_b_optimal = soroswap_library::quote(amount_a_desired.clone(), reserve_a.clone(), reserve_b.clone());

The Library Contract: Comparison between Soroswap and UniswapV2

esteblock — Wed, 04 Oct 2023 12:12:05 +0000

The UniswapV2Library contract is a contract that helps the router, or any other Uniswap Client Contract to interact with the Pair contract. It helps sort tokens (remember that for the pair contract it's not the same token0 than token1), get reserves for an specific pair, and calculates the optimal in/out amount someone needs to send to swap an specific quantity of an specific token.

In the following we are going to analize each function or characteristic of the UniswapV2Library contract, originally written in Solidity for EVM's, and we are going to think on how we could implement those functionalities and functions in rust for Soroban:

Safe Math:

In Solidity, the SafeMath library is used to validate arithmetic operations and prevent integer overflow/underflow. Should such a situation arise, the library throws an exception, which effectively reverts the transaction.

In Rust, we can achieve similar functionality by activating the overflow check flag during the compilation process with the following code:

[profile.release]
overflow-checks = true

Additionally, we use an overflow-safe implementation of functions checked_add, checked_mul, checked_div, and checked_sub. You can explore these functions and test their functionality in this repository: Overflow Soroban Repository

Also, we have overflow-safe functions checked_add, checked_mul, checked_div and checked_sub

You can check and test these techniques in the following repository: Overflow Soroban Repository

In conclusion, Soroswap prevents overflows by leveraging these techniques.

The `sortTokens` function:

This function returns sorted token addresses, used to handle return values from pairs sorted in this order.

In Solidity the code is like this:

function sortTokens(address tokenA, address tokenB) internal pure returns (address token0, address token1) {
        require(tokenA != tokenB, 'UniswapV2Library: IDENTICAL_ADDRESSES');
        (token0, token1) = tokenA < tokenB ? (tokenA, tokenB) : (tokenB, tokenA);
        require(token0 != address(0), 'UniswapV2Library: ZERO_ADDRESS');
    }

As you can see on our SoroswapPair contract, we have imposed that:

if token_a >= token_b {
            panic!("token_a must be less than token_b");
        }

Hence, we will implement an order of this type.

Regarding the zero address, in Soroban there is no such as zero address (read this discussion), so the last require statement won't be implemented.

The `pairFor` function

This function calculates the CREATE2 address for a pair without making any external calls. This is because UniswapV2Factory uses the CREATE2 opcode by carefully selecting a unique salt value in order to have a deterministic contract address for each (factory, token0, token1) combination (and of course the same pair contract code)

The whole idea of this function is to avoid an external call to the Factory contract in order to ask it what the pair address is... In Soroban this external call won't be expensive... and it's not event direct that calculating this address will be cheaper than the external call

Can we do the same with Soroban? The answer is yes!

In our SoroswapFactory contract, when we deploy a new Pair contract, we do it like this:

e.deployer()
    .with_current_contract(token_pair.salt(&e)) // Use the salt as a unique identifier for the new contract instance
    .deploy(pair_wasm_hash) // Deploy the new contract instance using the given pair_wasm_hash value

Here, the salt is an unique identifier that will be used to calculate the new smart contract address. In fact, the new smart contract address depends only in the combination of the deployer address and the salt.

In fact, in the salt in the factory is created by a combination of the token_0 and token_1 address:

impl Pair {
    pub fn new(a: Address, b: Address) -> Self {
        if a < b {
            Pair(a, b)
        } else {
            Pair(b, a)
        }
    }

    pub fn salt(&self, e: &Env) -> BytesN<32> {
        let mut salt = Bytes::new(e);

        // Append the bytes of token_a and token_b to the salt
        salt.append(&self.0.clone().to_xdr(e)); // can be simplified to salt.append(&self.clone().to_xdr(e)); but changes the hash
        salt.append(&self.1.clone().to_xdr(e));

        // Hash the salt using SHA256 to generate a new BytesN<32> value
        e.crypto().sha256(&salt)
    }

    pub fn token_a(&self) -> &Address {
        &self.0
    }

    pub fn token_b(&self) -> &Address {
        &self.1
    }
}

If you want to be sure about what we say here, please check this playground repo: https://github.com/paltalabs/deterministic-address-soroban

So, in Soroban we can also calculate the pair contract address without doing a cross-contract call to the Factory contract, we just need the salt explined above + the Factory address like this:

pub fn calculate_address(
    env: Env, 
    deployer: Address,
    salt: BytesN<32>,
) -> Address {

    let deployer_with_address = env.deployer().with_address(deployer.clone(), salt);

    // Calculate deterministic address:
    // This function can be called at anytime, before or after the contract is deployed, because contract addresses are deterministic.
    // https://docs.rs/soroban-sdk/20.0.0-rc2/soroban_sdk/deploy/struct.DeployerWithAddress.html#method.deployed_address
    let deterministic_address = deployer_with_address.deployed_address();
    deterministic_address
}

The `getReserves` function

This function fetches and sorts the reserves for a pair.

It's code in Solidity is:

function getReserves(address factory, address tokenA, address tokenB) internal view returns (uint reserveA, uint reserveB) {
        (address token0,) = sortTokens(tokenA, tokenB);
        (uint reserve0, uint reserve1,) = IUniswapV2Pair(pairFor(factory, tokenA, tokenB)).getReserves();
        (reserveA, reserveB) = tokenA == token0 ? (reserve0, reserve1) : (reserve1, reserve0);
    }

It is a set of simple external and internal function calls, so it will be easy to implement in Soroban

The `quote` function

This function given some amount of an asset and pair reserves, returns an equivalent amount of the
other asset

It's code in Solidity is:

function quote(uint amountA, uint reserveA, uint reserveB) internal pure returns (uint amountB) {
        require(amountA > 0, 'UniswapV2Library: INSUFFICIENT_AMOUNT');
        require(reserveA > 0 && reserveB > 0, 'UniswapV2Library: INSUFFICIENT_LIQUIDITY');
        amountB = amountA.mul(reserveB) / reserveA;
    }

It's a set of restrictions and arithmetics operations, so it will be implemented in Soroban without any problem.

The `getAmount...` functions

There are four important functions in Uniswap's code: getAmountOut, getAmountIn, getAmountsOut and getAmountsIn that are similar. These functions are used for making trades and managing liquidity in Uniswap.

getAmountOut` calculates how much of one token you can get when you put in another token, considering fees and available reserves.
getAmountIn does the opposite, determining how much you need to put in to get a specific amount of another token.
getAmountsOut and getAmountsIn` help with more complex trades that involve multiple steps, like going from Token A to Token B to Token C. They make sure you get the right amount at each step.

These operations involve math and checks. These same operations can be easily recreated in Rust and Soroban.

Deterministic Address in Soroban

esteblock — Wed, 04 Oct 2023 11:46:19 +0000

with Soroban, the Smart Contract Platform on Stellar we can know what the address of an smart contract will be, when we deploy the contract using a Deployer contract or Factory contract.

In fact, from after soroban-sdk version 20.0.0-rc2 we can use the deployed_address method for a DeployerWithAddress struct. For more information please check the documentation here: https://docs.rs/soroban-sdk/20.0.0-rc2/soroban_sdk/deploy/struct.DeployerWithAddress.html#method.deployed_address

We can calculate the contract address like this:

pub fn calculate_address(
    env: Env, 
    deployer: Address,
    salt: BytesN<32>,
) -> Address {

    let deployer_with_address = env.deployer().with_address(deployer.clone(), salt);

    // Calculate deterministic address:
    // This function can be called at anytime, before or after the contract is deployed, because contract addresses are deterministic.
    // https://docs.rs/soroban-sdk/20.0.0-rc2/soroban_sdk/deploy/struct.DeployerWithAddress.html#method.deployed_address
    let deterministic_address = deployer_with_address.deployed_address();
    deterministic_address
}

I wrote a playground repo available here: https://github.com/paltalabs/deterministic-address-soroban

Where we answer the following questions:

1. Same WASM, different salt ✅

Can a deployer deploy 2 contracts with same WASM and different salt?

Answer: ✅ Yes!

Check test_deploy_from_contract_twice_same_wasm_different_salt

2. Same WASM, same salt ❌

Can a deployer deploys 2 contracts with same WASM and same salt?

Answer: ❌ No!

Check test_deploy_from_contract_twice_same_wasm_same_salt_should_panic

3. Different WASM, same salt ❌

Can a deployer deploys 2 different contracts (different WASM) with same salt?

Answer: ❌ No!

Check test_deploy_from_contract_different_wasm_same_salt_should_panic

This proves that in fact the contract addresses does not depend on the WASM, but on the combination of address & salt

4. Two deployers, same WASM, same salt ✅

Can one deployer deploys a (wasm/salt) and another deployer deploys the same (wasm/salt)?

Answer: ✅ Yes!

Check test_deploy_from_two_contract_deployers_same_wasm_same_salt

They have indeed different contract addreess, because, again, the contract address depends on the combination of address&salt.!!

5. Calculate a deterministic address

Can we calculate the address of a contract only knowing the address of the factory that will (or that already did) deploy the contract and the salt used (or to be used)?

Answer: ✅ Yes!

Check test_calculate_address

After soroban-sdk = { version = "20.0.0-rc2" }, we can use the deployed_address method for a DeployerWithAddress struct. For more information please check the documentation here: https://docs.rs/soroban-sdk/20.0.0-rc2/soroban_sdk/deploy/struct.DeployerWithAddress.html#method.deployed_address

The Router Contract: Comparison between Soroswap and UniswapV2

esteblock — Tue, 12 Sep 2023 15:45:50 +0000

Check this and more in docs.soroswap.finance

Until now, we have developed the Factory and the Pair contract. The factory knows how many pairs it has created and can give us their contract addresses. Also, if we want to trade between token A and token B, and if that pair exists, the Factory will also give us the corresponding pair contract address.

But what happens if there are two pairs, A-B and B-C, and a user wants to make a trade between A and C? We could first trade A to B and then B to C! This is why we have the Router Contract.

The Router Contract allows swapping of tokens when a direct pair does not exist. It also handles liquidity provision and manages deposit and withdrawal functions for liquidity providers within the Soroswap ecosystem.

The native token: ETH, WETH, and XLM.

In the UniswapV2Router02, there is a very important distinction between any ERC20 tokens and the native token ETH (and its wrapped version WETH). In particular, in the contract we find:

address public immutable override WETH;

With UniswapV2Router02, if you are using ETH, you'll need to use special functions:

addLiquidityETH instead of addLiquidity
removeLiquidityETH instead of removeLiquidity
removeLiquidityETHWithPermit instead of removeLiquidityWithPermit
Instead of just having swapExactTokensForTokens and swapTokensForExactTokens; Uniswap Router needs to add 4 extra functions: swapExactETHForTokens, swapTokensForExactETH, swapExactTokensForETH, swapETHForExactTokens.
Instead of just having swapExactTokensForTokensSupportingFeeOnTransferTokens, Uniswap Router needs to add 2 extra functions: swapExactETHForTokensSupportingFeeOnTransferTokens and swapExactTokensForETHSupportingFeeOnTransferTokens

This is because it's very common that in Blockchains, the native token (in this case ETH in Ethereum) is treated differently, so the smart contract needs to trigger different functions when transferring the native token.

What about in Soroban?

Well, in Soroban, we won't need to have all these extra functions! This is because the native XML token has its own token contract address and can be treated as any other token complying with the token interface.

You can find more information about this in the Soroban Token Playground Chapter 8, 9, 10, and 11.

Conclusion:
Only the following functions will be written:

function addLiquidity
function removeLiquidityWithPermit
function swapExactTokensForTokens
function swapTokensForExactTokens
function swapExactTokensForTokensSupportingFeeOnTransferTokens

The following functions won't be written:

function addLiquidityETH
function removeLiquidityETH
function removeLiquidityETHWithPermit
function swapExactETHForTokens
function swapTokensForExactETH
function swapExactTokensForETH
function swapETHForExactTokens
function swapExactETHForTokensSupportingFeeOnTransferTokens
function swapExactTokensForETHSupportingFeeOnTransferTokens

Also, because we will treat XML as any other token, we won't need to define its address. We won't need to write something like:

address public immutable override WETH;

Finally, there is also no need for this function:

receive() external payable {
        assert(msg.sender == WETH); // only accept ETH via fallback from the WETH contract
    }

as XML can only be sent using the native contract.

SafeMath

In Rust, we can achieve similar functionality by activating the overflow check flag during the compilation process with the following code:

[profile.release]
overflow-checks = true

Also, we have overflow-safe functions checked_add, checked_mul, checked_div and checked_sub

You can check and test these techniques in the following repository: Overflow Soroban Repository

In conclusion, Soroswap prevents overflows by leveraging these techniques.

Deadlines

In Ethereum we can send a transaction with low gas price, and that transaction could be accepted 5, 10 or more minutes later. In order to avoid unwanted transactions after a period of time, Uniswap introduces the deadline parameter and the ensure(deadline) modifier:

modifier ensure(uint deadline) {
        require(deadline >= block.timestamp, 'UniswapV2Router: EXPIRED');
        _;
    }

In Soroban, we can think that having a transaction waiting for minutes is something that can never happen. But because we don't want to say never, Soroswap will include this "deadline modifier."

Modifiers do not currently exist in the soroban-sdk. So we'll need to build a special function using the env.ledger().timestamp() object.

Permit

In UniswapV2Router02 we use the permit method of the UniswapV2ERC20.sol contracts that is defined here:

 function permit(address owner, address spender, uint value, uint deadline, uint8 v, bytes32 r, bytes32 s) external {
        require(deadline >= block.timestamp, 'UniswapV2: EXPIRED');
        bytes32 digest = keccak256(
            abi.encodePacked(
                '\x19\x01',
                DOMAIN_SEPARATOR,
                keccak256(abi.encode(PERMIT_TYPEHASH, owner, spender, value, nonces[owner]++, deadline))
            ) 
        );
        address recoveredAddress = ecrecover(digest, v, r, s);
        require(recoveredAddress != address(0) && recoveredAddress == owner, 'UniswapV2: INVALID_SIGNATURE');
        _approve(owner, spender, value);
    }

This function implements EIP-2612. This avoids the user to use 2 transactions approve and `transfer, which allows users to modify the allowance mapping using a signed message. this function allows a token holder to grant permission for a specific address (spender) to spend their tokens up to a certain amount (value) with a specified expiration time (deadline). The signature ensures the authenticity of the permit, and the function enforces that the permit hasn't expired and that it was signed by the legitimate token owner.

In Soroban we don't need to implement something like this, as we use the require.auth() method when sending tokens from the user into the smart contract.

Conclusion: We don't need to impement the removeLiquidityWithPermit, neither the removeLiquidityETHWithPermit functions (neither removeLiquidityETHWithPermitSupportingFeeOnTransferTokens)

Fees on Transfer

In UniswapV2, there is a special function that allows the user to swap tokens that charge a fee when doing a transfer. This tokens are popular in the deflactionist community, and indeed it made Uniswap upgrade their original UniswapV2Router (latter called UniswapV2Router01) contract to a UniswapV2Router02 version!

You can read all the discussion of the Uniswap design in this issue

In the code we see many functions that have the word SupportingFeeOnTransferTokens:

_swapSupportingFeeOnTransferTokens
swapExactTokensForTokensSupportingFeeOnTransferTokens
swapExactETHForTokensSupportingFeeOnTransferTokens
swapExactTokensForETHSupportingFeeOnTransferTokens
removeLiquidityETHSupportingFeeOnTransferTokens

But in fact there is only two functions that do all the work: _swapSupportingFeeOnTransferTokens and removeLiquidityETHSupportingFeeOnTransferTokens

These functions work equal to _swap and removeLiquidityETH but succeeds for tokens that take a fee on transfer.

Because in Soroswap we want to support all types of tokens, we will implement these logics in the SoroswapRouter contract!

library UniswapV2Library

UniswapV2Router uses the UniswapV2Library. This is something that Soroswap will also develop

What's next?

Write rust!

DEV Community: esteblock

Fullstack Blockchain Job Offer

Oferta de Trabajo Fullstack Blockchain

Costs, DoS Risks, and Instance vs Persistent Data Types in Soroban

TLDR;

Instance and Persistent Data Types.

The Challenge: Store Unbounded Information

Design 1: Store a Vector in an Instance Data Type. The Case of a Light Smart Contract.

Design 2: Store a Vector in an Instance Data Type.. The Case of a Heavy Smart Contract.

Design 3: Store a Vector in a Persistent Data Type..

Design 4: Use Variable DataKeys with Persistent Data Type..

Design 5: Use Variable DataKeys with Instance Data Type.

Contact us:

Managing different Soroban CLI versions

The Soroban Preview Docker Image

How to use this together with a Quickstart Image node?

Run the Containers:

Do it your self.

Installing Freighter

1. Installing Freighter

Step 1: Installing Freighter on your Browser

Step 2: Safeguarding Your Wallet

Step 3: Confirming Your Seed Phrase

Step 4: Accessing Your Wallet

Step 5: Let's Dive into the Tutorial

Soroswap 🪐 on Testnet Overview

Soroswap Testnet Overview

User-Friendly Interface

Key Features and Benefits

Soroswap.Finance 🪐 is live on Soroban Testnet ✨!

Welcome to Soroswap.Finance

Converting a Soroban Smart Contract into a crate library

The Library Contract

Publishing into crates.io

Importing it into your code:

The "no external crate" error

Moving out your desired functions.

Using the library

The Library Contract: Comparison between Soroswap and UniswapV2

Safe Math:

The sortTokens function:

The pairFor function

The getReserves function

The quote function

The getAmount... functions

Deterministic Address in Soroban

1. Same WASM, different salt ✅

2. Same WASM, same salt ❌

3. Different WASM, same salt ❌

4. Two deployers, same WASM, same salt ✅

5. Calculate a deterministic address

The Router Contract: Comparison between Soroswap and UniswapV2

The native token: ETH, WETH, and XLM.

SafeMath

Deadlines

Permit

Fees on Transfer

library UniswapV2Library

What's next?

The `sortTokens` function:

The `pairFor` function

The `getReserves` function

The `quote` function

The `getAmount...` functions