Forem: Mohammed Alsabaawi

Atom transactions using Jito bundles

Mohammed Alsabaawi — Mon, 02 Dec 2024 11:18:34 +0000

Summary

In this blog, you learn:

The Solana transaction size limitation
Jito bundles, what they are, and why we need them
A practical example with TS on how to build and submit a Jito bundler to the network (Github repo)

Introduction

Solana is a fast, cheap, and performant network; it has a very high TPS, the best of all other chains. But we are not living in a perfect world; everything comes with a price. When you make something that good and cheap, tradeoffs are inevitable. One of these tradeoffs is the transaction size limitation.

Solana transaction size limitation

Solana network enforces a 1232-byte transaction size limit to ensure each transaction fits into a single network packet. This design choice is deliberate and efficient. Solana network adheres to a maximum transmission unit (MTU) size of 1280 bytes, consistent with the IPv6 MTU, and after accounting for the necessary headers (40 bytes for IPv6 and 8 bytes for the fragment header), 1232 bytes remain available for packet data. You can read more about this here

While this is sufficient for most use cases, there are times when you might need more. And if, for some reason, you want to have two transactions, and you want one of them to get submitted before the other, and you want to make sure that the second transaction never reaches the network if the first one has some issues,

You can't sign and send both transactions simultaneously because there's no guarantee the first transaction will be submitted first. Instead, you must sign and submit the first transaction, wait for confirmation, then sign and submit the second. This process creates a poor user experience, as users must sign twice for a single action. So, what's the solution? Here comes Jito Bundles

Jito

Jito is one of the biggest projects on the Solana network; they do a lot of cool things (check their blog), but we are now interested in the Jito Bundles feature. Jito Bundles consist of up to five transactions that execute sequentially and atomically, ensuring an all-or-nothing outcome.

How do Bundles work?

Traders submit bundles to block engines
Block engines simulate bundles to determine the most profitable combinations
Winning bundles are sent to validators to include in blocks
Validators execute bundles atomically and collect tips

Practical Example

In this example, you will build and submit a bundle to Jito. You can find the example code in this GitHub repo

Similar to Solana's priority fees, Jito employs a mechanism to prioritize bundles called 'Jito tips.' These user-defined amounts incentivize validators to process bundles ahead of other transactions, ensuring faster execution.

Tips are simply a SOL transfer instruction to one of the known Jito tip accounts, and this instruction should be present in your bundle either as a part of another transaction or as a stand-alone transaction, we will look at both of them here.

If you go ahead and clone the repo, open the readme file and follow the instructions to install the dependencies (I use a bun, but feel free to use something else) and set up the env variables, then you can find two files inside the src folder, embedded-tip-ix.ts and separated-tip-tx.ts, they are pretty similar, the only change is that we are embedding the tip instruction in one of the bundle's transactions (the last one) in one of them, while we are separating it into a standalone transaction in the other one, you can read more about the best practices of tipping here and here

TL;DR: you should try to have the tipping instruction as the last one in the bundle, and it is better to have it inside a transaction and not a stand-alone transaction, in this case, you will make sure that your tip will not go for wast by a malicious validator or an uncle block

Now let's take a look at the file src/embedded-tip-ix.ts and skip the import part (because it is boring), the first function that you will see there is getRandomeTipAccountAddress

const getRandomeTipAccountAddress = async (
  searcherClient: searcher.SearcherClient,
) => {
  const account = await searcherClient.getTipAccounts();
  return new PublicKey(account[Math.floor(Math.random() * account.length)]);
};

This function fetches the tip accounts and selects a random one. Using a random account instead of always selecting the first one increases the chance of landing our bundle, if too many transactions try to tip the same account, that might push some of them to fail.

The very next thing is the buildMemoTransaction:

const MEMO_PROGRAM_ID = "Memo1UhkJRfHyvLMcVucJwxXeuD728EqVDDwQDxFMNo";

const buildMemoTransaction = (
  keypair: Keypair,
  message: string,
  recentBlockhash: string,
  tipIx?: TransactionInstruction,
): VersionedTransaction => {
  const ix = new TransactionInstruction({
    keys: [
      {
        pubkey: keypair.publicKey,
        isSigner: true,
        isWritable: true,
      },
    ],
    programId: new PublicKey(MEMO_PROGRAM_ID),
    data: Buffer.from(message),
  });

  const instructions = [ix];

  if (tipIx) instructions.push(tipIx);

  const messageV0 = new TransactionMessage({
    payerKey: keypair.publicKey,
    recentBlockhash: recentBlockhash,
    instructions,
  }).compileToV0Message();

  const tx = new VersionedTransaction(messageV0);

  tx.sign([keypair]);

  console.log("txn signature is: ", bs58.encode(tx.signatures[0]));
  return tx;
};

Just a simple method that will build a memo transaction, which has no use, but it is so cheap and simple, so it is perfect for our example since we are going to do this on the main net, it also takes an optional tip instruction and pushes it in the transaction if provided.

Sitting that aside, let's get to the meat of this, the first few lines of the main function is just to setup few variables.

const main = async () => {
  const blockEngineUrl = process.env.BLOCK_ENGINE_URL || "";
  console.log("BLOCK_ENGINE_URL:", blockEngineUrl);

  const authKeypairPath = process.env.AUTH_KEYPAIR_PATH || "";
  console.log("AUTH_KEYPAIR_PATH:", authKeypairPath);
  const decodedKey = new Uint8Array(
    JSON.parse(Fs.readFileSync(authKeypairPath).toString()) as number[],
  );
  const keypair = Keypair.fromSecretKey(decodedKey);

  const bundleTransactionLimit = parseInt(
    process.env.BUNDLE_TRANSACTION_LIMIT || "5",
  );

After that, we need to create the searcher client, which is what we will use to communicate with the Jito server

  // Create the searcher client that will interact with Jito
  const searcherClient = searcher.searcherClient(blockEngineUrl);

And we can subscribe to the onBundleRequest so we get updates about our bundle once we send it to the network

  // Subscribe to the bundle result
  searcherClient.onBundleResult(
    (result) => {
      console.log("received bundle result:", result);
    },
    (e) => {
      throw e;
    },
  );

Then we will get the tip account and build the tip instruction

  // Get a random tip account address
  const tipAccount = await getRandomeTipAccountAddress(searcherClient);
  console.log("tip account:", tipAccount);

  const rpcUrl = process.env.RPC_URL || "";
  console.log("RPC_URL:", rpcUrl);

  // get the latest blockhash
  const connection = new Connection(rpcUrl, "confirmed");
  const blockHash = await connection.getLatestBlockhash();

  // Build a Transfer Instruction
  const tipIx = SystemProgram.transfer({
    fromPubkey: keypair.publicKey,
    toPubkey: tipAccount,
    lamports: 1000,
  });

As mentioned earlier, the tip can be included in one of the bundle transactions. Alternatively, it can be a stand-alone transaction.

  const transactions = [
    buildMemoTransaction(keypair, "jito test 1", blockHash.blockhash),
    // Include the tip instruction in the second transactions
    buildMemoTransaction(keypair, "jito test 2", blockHash.blockhash, tipIx),
  ];

but we can also have it as a stand-alone transaction like this

  const tipTx = new VersionedTransaction(
    new TransactionMessage({
      payerKey: keypair.publicKey,
      recentBlockhash: blockHash.blockhash,
      instructions: [tipIx],
    }).compileToV0Message(),
  );
  tipTx.sign([keypair]);

  const transactions = [
    buildMemoTransaction(keypair, "jito test 1", blockHash.blockhash),
    buildMemoTransaction(keypair, "jito test 2", blockHash.blockhash),
  ];

With everything in place, we can now build the bundle using the transactions and submit it to Jito.

  const jitoBundle = new bundle.Bundle(
    [...transactions, tipTx],
    bundleTransactionLimit,
  );

  try {
    const resp = await searcherClient.sendBundle(jitoBundle);
    console.log("resp:", resp);
  } catch (e) {
    console.error("error sending bundle:", e);
  }

here is the full file from the example src/embedded-tip-ix.ts link

Now if you run that file, you should see the transaction signatures and the bundle Id, you can check the transactions in any explorer and you can check the bundle id in Jito Explorer (it might take a minute before showing up there)

txn signature is:  5YQVsedCaaf1bCbTUJgd23vNfte2doB1K3CB6tKxCH7KYY7Y8rDwbmetCcgBufhz8nY1nWDeCRNqhUkWNydnsjeZ
txn signature is:  3mnhGK2X2FVnsada8YL46TYdZc7BfR14GdYTjJWk8mrG2WzBJGXdyN7aLVNP3ZkWGwUBpGypjW7JWFeYGKNRa2vR
resp: 09d2c693a232d48781f69d786276b8af04be9138b0777d313b18251271825b3c

Congrats, you have submitted a bundle

Conclusion

Jito Bundles provide a powerful solution for handling Solana’s transaction size limitations, ensuring seamless and atomic execution of complex operations. By leveraging tips and smart transaction bundling, developers can optimize the user experience and make the most of Solana’s capabilities. With this guide and the provided example, you now have the tools to integrate Jito Bundles into your Solana projects effectively. Try it out and explore the possibilities!

Solana Safe Transfer (Fat-Finger-proof Transfer)

Mohammed Alsabaawi — Sat, 02 Nov 2024 14:10:03 +0000

Solana is a fast, cheap, and reliable blockchain network. You can transfer assets worth millions of dollars in seconds to another part of the world. And you'll pay only a fraction of a penny in fees!

This technology is revolutionary, and finance is not the only thing you can do on it with such efficiency. People are doing lots of cool stuff on this network, like running DAOs or building games with experiences different from what we had before blockchain.

When it comes to finance and money, one of the key differences between traditional banking systems and blockchain (Solana in particular) is speed. Traditional banking systems are slow if you want to send money overseas, and if it's a large sum, you’ll have to pay high fees. The trade-off is security because the bank will double-check the transfer details before sending it. If you make a mistake, like entering the wrong account number, and that number doesn’t belong to anyone, the bank won’t process the transfer, and the money will return to your account.

Using Solana, on the other hand, is much faster and cheaper. You can send assets worth thousands of dollars in seconds—literally seconds—but there’s a catch: once you sign the transaction and send it to the network, there's no way to reverse it. No one can undo it, ever! This is good for network security, but if you accidentally enter the wrong address, it’s a problem for you.

If you change even one letter in the address (which is around 32-44 characters long), you could lose access to those assets forever. There’s a chance that the funds might end up in an account that no one owns—and probably never will. That’s why people are often hesitant to send large amounts of assets over the network.

This is where my program, Solana Safe Transfer, comes into play. It requires you to enter the recipient's address as well as a unique confirmation code associated with that address. If there are any mistakes in either of these strings, the transfer will fail, and your assets will remain in your account.

How It Works

Get a Confirmation Code

To get a confirmation code that you can share with others for sending you money, go to the Program website. There, click the Get a Confirmation Code button, and sign a light transaction that will create a confirmation account for you and generate a random code for the wallet you're using. After that, you can copy the code and share it with anyone who wants to transfer funds to you.

Transferring Assets

To send assets, visit the same Program website. From there, you can enter the amount of SOL you want to send, provide the recipient's address, and their confirmation code, then hit send. Right now, the program supports sending SOL, but I’ll be adding support for other SPL tokens as well as NFTs soon.

Feel free to share any feedback you have, or let me know what features you’d like me to work on next. If you want to get involved and help, please be my guest—here is the repo.

My Experience at Nas Academy Solana Course: A Journey into the World of Web3

Mohammed Alsabaawi — Thu, 08 Jun 2023 10:21:11 +0000

Introduction:

Recently, I had the incredible opportunity to participate in the Nas Academy Solana Course, a bootcamp designed to explore the modern web technology known as Web3. As a full-stack software engineer with a keen interest in the latest advancements, I was eager to delve into this new world and evaluate its potential. In this blog post, I will share my background, discuss my experience throughout the course, highlight the valuable knowledge gained, and provide insights on what could be improved.

Background and Motivation:

With over three years of experience as a software engineer working on web2 projects, I was eager to expand my horizons and dive into the realm of Web3. The opportunity to learn from the best in the field motivated me to join the Nas Academy Solana Course. Having witnessed the impressive work produced by Nas Academy, I was confident that this bootcamp would provide an enriching experience.

Experience at Nas Academy:

My journey at Nas Academy began with an engaging speaker session before the start of my cohort. There, I had the pleasure of meeting the enthusiastic and knowledgeable Nas crew. Their vibrant energy and passion for the subject instantly captivated me, setting the stage for an exciting learning experience. The course itself was led by James, an exceptional teacher and engineer who provided valuable insights into Solana development. Through his guidance, I learned not only about Solana but also about debugging techniques and other essential skills.

Furthermore, the presence of Giorgio, an amazing support system for the students, with his infectious energy, was a dedicated support system throughout the course. Always available to help students when they encountered challenges, he played a pivotal role in creating a supportive and collaborative learning environment. Her commitment to ensuring everyone's success was truly commendable.

and A.J. though not directly involved in technical aspects, contributed significantly to the smooth functioning of the course. She was responsible for organizing the sessions, managing logistics, and uploading the session recordings. Her efforts behind the scenes ensured that everything ran seamlessly, allowing participants to focus on the learning experience without any distractions.

Key Takeaways:

Throughout the Nas Academy Solana Course, I acquired a comprehensive understanding of Solana and its potential applications. From developing front-end applications that interacted with existing Solana programs, to creating fungible tokens, NFTs, and candy machines, I gained hands-on experience in building decentralized applications. Moreover, I learned how to write my own programs using vanilla Rust and the Anchor framework, and successfully deployed them on the Solana blockchain. The course also enlightened me about the fundamental concepts of Web3 and reinforced my belief that it represents the future of the internet.

Favorite Aspects of the Course:

One of the standout features of the Nas Academy Solana Course was its exceptional organization and professionalism. The sessions were conducted punctually, with a perfect balance between pace and interactivity. I appreciated that there was ample time to ask questions and learn from the best in the field. Additionally, the offline course material provided was incredibly informative, enriching the overall learning experience.

Suggestions for Improvement:

While the course offered a well-rounded learning experience, one aspect that I would have appreciated is the inclusion of code reviews. As someone who greatly values feedback on my code, I believe that incorporating a few additional weeks at the end of the course for a capstone project, where participants can receive expert reviews on their code, would have been a valuable addition.

Conclusion:

My time at Nas Academy Solana Course was a remarkable journey into the world of Web3. The course instructors, James, Jorgie, and A.J., provided exceptional guidance and support, making the learning experience enjoyable and enlightening. I gained in-depth knowledge of Solana development, learned essential debugging techniques, and explored the concept of Web3 as the future of the internet. Although I would have appreciated the opportunity for code reviews, I highly recommend this bootcamp to anyone interested in immersing themselves in the exciting world of Web3.

A Better Way to Deal With Dependencies

Mohammed Alsabaawi — Mon, 04 Jul 2022 05:57:45 +0000

Dependencies are everywhere right now and are always a necessary part of developing any app; however, occasionally our code can easily become highly coupled with them and this is extremely risky. As a result, our app will eventually go down sooner than we expect when one of the dependencies goes down for any reason, and to make it worse external code is out of our control which makes it much harder to deal with, another thing to consider when using a lot of dependencies is changing one of them, that could be also hell and needs a lot of work unless we plan for it carefully to manage the dependencies in a way that makes it less dangerous to use them.

There are several approaches to achieve this, including and not limited to "dependency injection" and "dependency inversion", and in this post, we will discuss a strategy related to dependency inversion

The Problem:

Assume that we have a nodejs app and we need to use a library that generates a random number; by googling this, we could find quite a few of them, and we decide to use the library x-random-generator and we need to do this to generate a random number.

import xRandomGenerator from `x-random-generator`

const randomNumber = xRandomGeneration.generateRandomNumber()

and let's say that this library generates also random IDs and we will use it like this

import xRandomGenerator from `x-random-generator`

const randomId = xRandomGeneration.generateRandomId()

we went ahead and used this in our code, and we used this library in up to X number of files, and everything is working fine.

After a while, the app grows a little bit more, and now we have a new feature that needs to use a random username using only a special set of characters. we went back to our library and after reading its documentation, we can see that we can't use it to generate the random username we need because this library uses a set of characters containing this - and _, but those are not allowed in our username so what should we do now?

we went ahead and found a cool library called y-random-generator that provides this feature as well as random numbers and random IDs; and because we can't use both of them, so we need to replace the old one with this one, and because we have used it in many places, we will have to touch all the files that used the old library, and this is never a good idea specially if the new library have a different interface.

The Solution:

to avoid this problem we will have to hide our dependencies, no part of our app should ever know which library this part of code is coming from, only one component should know that, and we should use it abstract only the methods that we need to use out of the large library we use.
this component will look this

import yRandomGenerator from `x-random-generator`

export const randomGenerator = {
  randomNumber: yRandomGenerator.generateRandomNumber,
  randomId: yRandomGenerator.generateRandomId,
  randomUsername: yRandomGenerator.generateRandomUsername,
}

We may use this new component across our entire application, and whenever we wish to switch to a different library —even a one that might even have a very different interface— this component can act as an adopter to ensure that the code still functions properly for our application.

import ZRandomGenerator from `z-random-generator`

const zRandomGenerator = new ZRandomGenerator()
const zRandomUsernameGenerator = new ZRandomGenerator('abcdefghijklmnopqrstuvwxyz')

export const randomGenerator = {
  randomNumber: zRandomGenerator.numbers().generate,
  randomId: zRandomGenerator.generate,
  randomUsername: zRandomUsernameGenerator.generate,
}

conclusion:

To assist lessen the coupling to our dependents and to give ourself a little more freedom when we wish to update or change one of them, we should always aim to hide our dependencies under a layer of abstraction. and This even supports the "Single Responsibility Principle".