Aditi Maheshwari

All the best. What about am I giving the brief introduction of yourself? Sure. Hi. This is Aditi Desai. And, uh, um, so I come with around, you know, 9 years of experience. So my initially 2 years was into CC plus plus programming where I was writing code for the, uh, automobile industry. So then soon after that, you know, I was into blockchain where I have, uh, started writing, you know, a POCs in Hyperledger Factory 1.0 for the energy trading. Then after that, you know, like, for around 2 years, uh, when I was in Lipton Technologies, I was, uh, you know, in, again, same blockchain field. So there, you know I mean, I was writing smart contracts and solidity for the Quorum based Ethereum team where we had only one single project running an entire repro, which was, uh, Strala, which came from, uh, British Petroleum. So and I was the only blockchain developer from India. And, you know, also so my role there was majorly writing the smart contracts and the integrations. After, you know, around serving 4 years, 10 months in the group, Then I switched to persistence labs. So there I was for around 2 years, 10 months. So there, you know, I we have launched 2 tokens, and I was one of the, uh, uh, you know, core members there initially. And, uh, there, we launched 2 tokens. 1 was XPRT, and second one was, uh, p stake, which was, like, the governance token. So, you know, like, starting from, you know, the, um, smart contract development to the integration at the front end in the React. Js and the wallet connection in React JS. They were calling in calling the smart contracts from the front end, getting the data out of the blockchain, you know, getting the past events from the blockchain, and then writing the APIs in Node. Js. So it was all taken care by me. I've also, you know, uh, returned the persistence JS library in type script there. So after that, I switched to Comdex. There I was for around 1 year. Uh, and, uh, you know, mostly my again, we were, uh, developing a casino online casino. There again, you know, writing the pseudo codes, understanding how the calculation works, and implementing them into blockchain, the same Ethereum platform. Like, again, same thing writing the solidity smart contracts, integrating it to the front end and everything. Right now, I'm in unlimited here. I have, uh, joined in, uh, November. And, you know, here, I'm working in Go language. And, uh, so be uh, so whatever, you know, uh, the data which is available for the Uniswap smart order router, I'm implementing the same thing in Golang, though it is very challenging task. Why? Because the, you know, uh, all the import libraries for JavaScript, TypeScript, they are inbuilt. Like, we already have the pre different libraries. But for Golang, there is no such library. You know, I have to if I have to use a simple solidity dot pack function, I have to actually create the entire library within the code itself, and I'm able to use the function and, you know, then process the entire, uh, functions, uh, internally. So it was very challenging, you know, understanding how Uniswap, you know, does the exchanges, how it gets the swapped amount, how, you know, the code is being retrieved. So all the analysis was first done by me. Then entire you know, it like, how to implement it into whole and, like, you know, breaking down all the larger larger tasks into small small chunks and, you know, like, uh, all the updates, how it will you know, like, um, uh, to my manager, how I'm going to plan the entire work, then, you know, connecting it to the BA, like, how the input input and output, you know, data should look like in back end and front end, everything, so and so forth. So but, finally, I was able to, you know, do this thing in a very short span of time, you know, like, uh, if, let's say, one exchange, uh, a token amount is written, like, what will be the code for the exchange token b value, getting the multi hops, and so and so forth. So, yeah, this is pretty much about me.

To ensure atomic transactions since it's not contracts with dealing with multiple actions that will succeed update together. Okay. So what we can do is do here is either we can, uh, use the batching of transactions. So, you know, what happens is, like, let's say there are multiple, uh, similar types of transactions where, you know, people are trying to do the transfers or let's say now let's say assume let's assume, like, people are trying to do multiple transfers, and those are all similar kind of transactions. What we can do is we can batch them instead of sending to the smart contracts 1 by 1, you know, back and forth, like, where we can see, like, may due to many issues, due to, you know, or too much data being sent to the back end, uh, it might get, you know, uh, uh, failed or whatever. So what we can do is we can batch those transactions and send them as a single transaction. This way, you know, we can the gas price will be less, and it's like there's multiple, uh, you know, uh, things. So and, you know and also now let's say we are not doing for the batching of of the transactions. What we can do is we can, uh, perform it all the transactions in the sequential manner. So now let's say we can just see, like, what was the, you know, last, uh, block number when the transaction was sent and the it was it was cut. So we can wait until, you know, the, uh, until the non switch was set for the previous transactions if the transaction has succeeded or failed. And, you know, then only we'll be sending the next transactions because these are so many, you know, uh, multiple actions being going on back and forth. So many things like, you know, like, continuously pull pushing the data through the smart contracts and then, you know, so many activities going on. There are multiple states being changed one after the other. So because, let's say, if if the transfer happens, there's, like, 2 things. The sender, uh, balance gets reduced, and the receiver's balance gets updated. So, you know, there are multiple states being changed to form one single, um, uh, action. So, uh, what we can do is we can check out the notes. And once you let's say the notes thing has been, you know, uh, it has been, uh, succeeded or failed, then we can send the next set of transaction. But I feel like the batching of the transactions is the much better approach because this way, it will only you know, like, we can combine multiple transactions into one single, uh, we can wrap it in a one single, uh, you know, request and then send it across. Yeah.

The complex smart contract. Solid how would you construct a complex smart contract system and solve the various cross contract calls with minimal gas overhead? Okay. So what we can do is now let's say, even we have to, you know, ensure there are multiple calculations, like, uh, being, you know, in the, uh, being involved in the smart contract. So instead of, you know, doing those calculations like this, we can, you know, use the internal libraries like a safe math. What why? Because they already offer so many, you know, like, um, madam mathematical libraries, uh, predefined. We can simply, you know, use them. This way the gas cost gets reduced. Also, now let's say if we have, you know, one one function, which is doing a lot of things one after the other, we can actually break that function down into small small, uh, functions and then, you know, process it accordingly. Why? Because this will reduce the gas. This will reduce the gas over it. And, also, like, using the predefined libraries like the open zipline also, you know, uh, this way we can construct the complex smart contract code into a very, you know, in a very efficient way. Also, again, I would say the, you know, the last answer which I can say, the batching of transactions, this will again reduce the cost, uh, because see, if we send transactions 1 after the other, obviously, the gas price will be, you know, charged for transactions. But now let's say if you're combining the bunch of transactions in a one single request and then sending, of course, the, you know, gas transaction get, uh, gets reduced. So I would say, you know, like, um, if we have very complex things like using the internal libraries, of the transactions and sending sending. So, yeah, I I guess we can just manage. And, also, you know, like, the cost con cross contract calls where, you know, one contract is calling the another contract. It is pretty simple, actually. Why? Because we just, you know, can, uh, either, uh, use this, uh, other smart contract functioning our smart contract function and just use getter or setter calls. So, basically, while, you know, writing the things, we have to actually see, like, you know, what is the, uh, tran what is the function is actually doing, breaking it down. And then if all the getter functions are there, then, you know, making a separate function for all the getter functions and setters, this type of setting that, uh, changing the states towards the blockchain. So I would say this will do a very pretty good job. Yeah.

In the context of a trading bot interacting with smart contracts, how do you mitigate the risk of forefront running? The context of a trading bot. Okay. So, you know, uh, I would actually mention my experience where, you know, for the energy trading, he was running a trading bot, like, which was running in every 30 minutes. So what was happening was, uh, like, a smart contract, if we assume, it is something if we see, like, it can it could be think of as a larger database where so many you know, data is stored. But the problem is if I want to get the data, it is very difficult. So, uh, what happens is now let's say whenever transaction gets processed, we emit the event, okay, that this transaction has been done, and these are the, you know, the function name or the, you know, parameters as and then this is, uh, so and so states has been changed. What happens is we can, you know, traverse through all those so, also, uh, all those past functions. So the function in this get past events. So based on the block number from and to, we can actually, you know, you know, uh, filter through lot of past events which have already been existed or transacted in the blockchain. And then, you know, based on the filter of the data, then we can actually see. Now, again, now let's say there's a trading bot which is so this is, you know, getting the data into the blockchain, and this is how the trading bot runs for the getter function. Now let's say we have a set of things where a trading bot runs, something is happening. Let's say a buy order has been matched with a sell order. Understand me? Now, uh, let's say then we have to do a, you know, a buy, uh, buy or sell order transaction or, you know, the process the order that, uh, so and so has been, uh, you know, matched. So what happens is, like, in the smart contract, so it is like, you know, business logic. So many rules are written first. If all the rules matches, then the transaction will flow. Same thing in the bot also. We have to match all the transactions all the sorry. All the, you know, rules, then only we'll be sending. Why? Because, let's say, if the user's balance is 0, right, he gets not he should he shouldn't be buying anything. So these are, you know, internal checks that we have to use in trading bots so that, uh, while, you know, sending the transaction, it has already passed all those checks. Once those those checks have been passed, then we are good to go and interact with the smart contracts. And, you know, what happens is, like, uh, we also have to see that the authorization checks. Why? Because this reduces the, uh, risk of the future. Now let's say if someone has placed the order and is selling it to someone, I can't come in between and say, hey. I'm the seller here or I'm the buyer here. It shouldn't be like that. It should be a very process. It should also cross verify who's the address, who is it trying to buy, who is it trying to sell, and so and so forth. This way, we can reduce the risk. We can have the authorization. We can have the ownership smart contracts where we can see that, okay, this this user is having so and so admin rights or the or whatever rights. So, you know, like, we can actually define based on their user addresses, and then, you know, this way we can reduce the mitigation of the risk.

How might you use even emitters in Web 3 JS to update the UI in real time a transaction confirmations from the blockchain? Perfect. So this is the thing which I've already done in the past. So what happens is now let's say we already have a Node. Js API running, which what the it does is whenever, you know, block is cut, something new happens to the blockchain. It, you know, it, uh, per block, it tries to read what is what is the new state changes in some in something. So what we can do here is, like, you know, let's say a transaction has been occurred. The event has been emitted. It has been, you know, broadcasted that, okay, this has been done. And that event, you know, the, uh, if the Node JS, uh, you know, the Node JS, uh, or the Web 3 JS thing which we are running in the back end to, you know, uh, you know, that we are trying to filter out all the events what has been done. It, uh, you know, it it reads real time data and see, okay. Let's say Alex has sent so and so money to, um, Alan. So it tries, okay, user a has done some kind of try back to user b. So, basically, how we know is we have done a transaction. We have emitted the event. The, uh, Node JS or the Web 3 JS, whatever is running in the back end, it run it tries to, you know, uh, read the live data. It reads, okay. Something has happened because the new event is emitted. And this is how it knows because the, uh, you know, why event is emitted because the transaction is confirmed on the black block, uh, back end. The that is the blockchain. Then only the even gets submitted. Once the events is submitted, it gets read by the, uh, middle layer, uh, or the back end layer, like, whatever layer we have set the, you know, uh, even emitters. And, you know, once it gets read by them, they just can show, okay, that okay. Now this is the latest data we have because you know? And, uh, this is how we actually I would see the real time data gets updated. Yeah.

Okay. What factors would you consider when selecting a consensus mechanism for a private blockchain network? Okay. So I'll okay. So, you know, there are different kinds of, uh, blockchain network available. So it depends on whether we need a permission or permission list. Now here, I talk about private. Now let's say, uh, an organization needs a KYC of a user, and different organization is already holding its KYC. Now let's say organization 1 asked to get the KYC from the organization 2. Now this way, the organ because the KYC data is encrypted and, you know, it is very confidential for any user, the organization too cannot simply, you know, go ahead and just send it to the network. Why? Because this is, you know, a confidential return cannot be sent across to the all the entities in the network. What it can does is it can have a private channel where it can, like, well, like, where, you know, like, in a very seamless manner, only organization 2 and organization 1 will be part of that channel. They can simply go and exchange the data. Here, okay, I'm not talking about the authority approvals from the user and so on, assuming it is already having it. So I'm just talking about why there's a need for the private channel here. And, also, private network is something, you know, where there's one centralized person who's holding the, uh, entire control of the network. That's how when we call it as a private blockchain network. You know, like, whatever happens and everything, it can regulate. It can, you know, uh, see why this has happened, so and so forth has happened. It is, like, centrally connected, I would rather say. And, uh, now let's say this was the KYC data. Now, you know, there are multiple other things where, you know, uh, where, uh, like, if we have to see, like, where all the major businesses are been whenever they think of a blockchain, they think of Corda because they have the central authority and they have the private network. They can do they can actually, you know, uh, regulate what the, you know, their nodes are doing, how they are operating, and if someone is faulted or not. So it depends on the business ID also. So I would say, yeah, that's my answer.

Here is a, uh, snippet of a smart contract in solidity means meant to emit an event. Explain if there's any mistake in the way the event is defined or emitted, and if so, how it might affect the contract's behavior. Event deposit, address, index, sender, u int amount. Okay? Function make deposit, public payable, emit deposit message dot sender, message dot value. Any mistake in the word event is defined or emitted. Okay. I think the first thing which I would say is basically the, uh, amount. Let's say it it should I I it should actually be, you know, you enter 256 here. And I see that, uh, message dot event. Okay. I I see that, uh, you know, what if the contracts? Behavior. Okay. You know, I think the thing which is wrong here is it is, you know, just embedding the event. It's not doing anything. If the function says it's if the function says payable, basically, you know, some kind of transactions should happen where the, uh, miss uh, the account, and account, and then the event should be emitted. Here, what is happening is we are, you know, just emitting the event saying that this, uh, that this sender has, you know, uh, deposited so and so value. But the thing is, it's just an event saying that this has been done, but there is no transaction. You know? Like, there is no underlying transaction which says this has actually been done. So, see, even there is something, it's just, you know, writing a note. It's just like sending a note. It's not a transaction here. It's just like sending a note. Okay. This thing has happened. But it doesn't mean that that has actually happened. For it to actually happen in the make deposit function for event emission, we actually have to do some kind of transactions or is the, you know, changing the states, uh, listening the balance of the user and then emit the event at the end. So I think, yeah, that's how because this is actually wrong.

Given the solid rating function below explained what the modifier only owner is likely doing before the function execution and identify any potential risk or issues with the implementation and as the owner is a mutable state variable. Mutable. Okay? Function, Okay. Modifier only owner require that message sender should be owner. Okay. Understood. Function withdraw public. Only owner. Okay. U n 256 balance equal to address of this not balance. So, okay, this is the contract's balance which we have retrieved. Message dot sender dot transfer. Okay. So, basically, see, only owner functions, what it does is, who so okay. Mutable state variable. Okay. Now let's say it's as we see that, you know, owner is a mutable state variable. Now let's say at the time of deployment or at the time of, you know, uh, like, explaining who will be the owner here. So owner, let's say there is some kind of admin role where we have a some admin user addresses. Okay. We are making that user address as the owner. Now let's say, uh, 0xabc is the owner here. Now if I go towards the smart contract, what is happening is 0xabc is, uh, is the owner. Okay. He might also be either the deployer or he might either be some user address. We we don't know. It depends on the situation. Now what is happening is now the someone is trying to call withdraw function. Now the problem is only owner means the owner which we have set, the 0 x a b c, And this and the person who's trying to call this withdraw function should be same. Then only it will enter, you know, to the withdraw function. Otherwise, it won't. Now the problem is as it is saying it is a mutable state variable, it means, you know, uh, it can, you know, basically change the state. Right? Like, let's say right now, the, uh, user address, a 0 x a, b, c, z. Later on, it can be 0 x, 123. It's in a very difficult to maintain it. Why? Because I would say you know, like, let's say, uh, as a admin, I used to know that 0 x a b c was the I'm the owner. I'm able to, you know, do the withdraw transactions. Now if someone else comes, we have given the rights. Okay. Now 0 x123 because it's a mutable state variable. It's the owner. So now 0 x a b c won't be able to call the assumption because we have the, uh, required check there as only. So, basically, I would say there's a potential risk of doing this.

Discuss an architecture for a scalable p app that involves an Ethereum block chain packet and a react and then detailing state management of chain storage considerations. Okay. This could be pretty vast. So now let's say I'm trying to, you know, have a decentralized application. Now let's say I have, um, home home token, maybe ATOM, let's say. I want to trade it. I want to stake it, unstake it, generate rewards out of it. Let's say it's a very decentralized application with 3 things. So what I'll do is I'll first, you know, start writing these smart contracts where for the, uh, for the, you know, for the token launch, let's say, for the add up. Okay? Or maybe we already have it. So okay. So my major, you know, major considerations would be writing a smart contracts for the staking, unsticking, and calculate reward. Assuming, you know, this has been done, I would be using hard hat for the, you know, for the testing to the deployment and everything, like, you know, for the management purpose, for checking and everything. So once now now, parallelly, what we can do is in the front end, once we have, you know, the entire blueprint ready, okay, this is how the UI looks like, there we can have the wallet integrations, you know, connecting to the blockchain where we have Ethereum dot web, maybe the MetaMask or Kepler. This is where where, you know, once the, um, smart contracts are deployed by the hard hat and once we get the their ABIs and, uh, contract addresses, we can use both of them, create the instance out of it, use it in the front end React JS code itself, and then, you know, call the, uh, back end functions. Uh, so it's a very pretty straightforward thing. And here, you know, like, uh, detailing the state management is or let's say, uh, user like, if I talk about the UI where user comes, they on the UI itself, uh, he enters the amount. Uh, like, obviously, the balance take everything already is it's in place there because those are all the getter things. I'm just trying to mention all the state changes here. So let's say he's entering amount 10. He clicks on stake function. Now internally in the smart contract, if the user is already having, you know, balance more than 10, it will go and try to stake it. Now the thing is from the user's balance, the 10 has been deducted, and the those ten values has been converted to a staked value now. So he'll be having 2 values, the normal amount and the staked amount. Now, basically, the states have been changed from the front end because we have called and do some transactions. Now now let's say if we I also wanted to have a, you know, off chain storage considerations where I can either, like, if I have to go for the free ones, I can go to postgreSQL or the MongoDB variable. Live live by live once the once I get the transaction received from the packet that, okay, this transaction is successful, I can then call the database, you know, and then store all the data, whatever I needed. If I needed a paid version, I can go to the AWS, use the DynamoDB relation DB, whatever. It actually depends on the requirement. So I would say this is the, you know, broader architecture how it will look like. Also, we can have a parallel Node JS, uh, application or Nextiva TypeScript application running, which monitors each and everything, what is happening and so on and so forth. That's my answer.

Illustrate the process of developing a custom Ethereum token and the considerations for ensuring compliance

How would you monitor the gas prices of pending transactions in the network to optimize gas fee win? How would you monitor the gas prices for pending transactions in the network to optimize the gas fee? Okay. So, you know, uh, we can go to the etherscan dot dot I o, and we can see there, you know, like, for that particular there are so many by the, um, uh, why the pending transactions are there? What are the gas price? So, basically, if you will know, if we go to the scanner dot I o, let's say, on the, you know, top left of the side, we can see the gas fee, the gas price, and, you know, the base fee and everything. Based on that, while deploying that, uh, smart contract, we can use those base fee gas fee, gas price, and, like, in the hard hat, uh, you know, configuration and simply, uh, you know, do it. And, also, for the, uh, uh, you know, the ERC, uh, contract, what we can do is, you know, like, we can use the open Zeppelin ERC 20 library where, you know, we have to simply, uh, you know, call their constructor, which is having name and symbol. Once we up do it once we do that, you know, uh, we and we can use their, you know, balance, uh, transfer in so many functions, which is internally in built, like the allowance, uh, the payables. Like, so many functions the r c 20 contract holds, so we can simply use them, optimize our contract, like, and deploy it. This way, we can have our own ERC 20 contract. So yeah.