Aditi Maheshwari

Hi. This is Aditi Desai. And, so I come with around 9 years of experience. So my initially 2 years was into C++ programming where I was writing code for the automobile industry. So then soon after that, I was into blockchain where I had started writing POCs in Hyperledger Fabric 1.0 for the energy trading. Then after that, like for around 2 years, I was in Lipton Technologies where I was in the blockchain field. So there, I was writing smart contracts and solidity for the Quorum-based Ethereum team where we had only one single project running, which was Strala, which came from British Petroleum. So I was the only blockchain developer from India. And, also, my role there was majorly writing the smart contracts and the integrations. After serving 4 years and 10 months in the group, I switched to persistence labs. So there I was for around 2 years and 10 months. So there, I was one of the core members initially, and we launched 2 tokens, XPRT and p stake, which was the governance token. So, starting from smart contract development to integration at the front end in React.js and the wallet connection in React.js, they were calling smart contracts from the front end, getting data out of the blockchain, getting past events from the blockchain, and then writing APIs in Node.js. It was all taken care by me. I've also returned the persistence.js library in TypeScript there. So after that, I switched to Comdex. There I was for around 1 year. And, mostly, my team was developing an online casino. There again, I was writing pseudo codes, understanding how the calculations work, and implementing them into blockchain, the same Ethereum platform. Like, again, same thing, writing solidity smart contracts, integrating it to the front end and everything. Right now, I'm in unlimited here. I have joined in November. And, here, I'm working in Go language. And, so, whatever data is available for the Uniswap smart order router, I'm implementing the same thing in Go. Because the import libraries for JavaScript, TypeScript, are inbuilt. Like, we already have pre-built libraries. But for Go, there is no such library. You know, I have to create the entire library within the code itself, and I'm able to use the function and then process the entire functions internally. So it was very challenging, understanding how Uniswap does the exchanges, how it gets the swapped amount, how the code is being retrieved. So all the analysis was done by me. Then, I broke down all the larger tasks into small chunks and, like, all the updates, how it will be, to my manager, how I'm going to plan the entire work, then connecting it to the BA, like, how the input and output data should look like in back end and front end, everything, so and so forth. So, but finally, I was able to do this thing in a very short span of time, like, if a token amount is written, 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 together. Okay. So what we can do is use the batching of transactions. So, you know, what happens is, like, let's say there are multiple similar types of transactions where, you know, people are trying to do the transfers or let's say assume people are trying to do multiple transfers, and those are all similar kinds 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, where we can see due to many issues, due to or too much data being sent to the back end, it might get failed. So what we can do is we can batch those transactions and send them as a single transaction. This way, you know, the gas price will be less, and it's like there's multiple things. So, and also, let's say we're not doing the batching of the transactions. What we can do is we can perform all the transactions in a sequential manner. So now let's say we can just see what was the last block number when the transaction was sent and it was cut. So we can wait until the non-switch was set for the previous transactions if the transaction has succeeded or failed. And then only we'll be sending the next transactions because there are so many multiple actions being done back and forth. So many things like, you know, continuously pulling data through the smart contracts and then so many activities going on. There are multiple states being changed one after the other. Because if the transfer happens, there's like two things. The sender's balance gets reduced, and the receiver's balance gets updated. So, you know, there are multiple states being changed to form one single action. So what we can do is we can check the status. And once the status thing has been succeeded or failed, then we can send the next set of transactions. But I feel like the batching of the transactions is the much better approach because this way, we can combine multiple transactions into one single request and then send it across. Yeah.

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, even if we have to ensure there are multiple calculations involved in the smart contract. So instead of doing those calculations, we can use the internal libraries like Safe Math. What's the reason? Because they already offer many predefined mathematical libraries. We can simply use them. This way, the gas cost gets reduced. Also, if we have one function doing a lot of things one after the other, we can break that function down into small functions and process it accordingly. Why? Because this will reduce the gas cost. And also, like, using predefined libraries like Open Zipline, we can construct the complex smart contract code in a very efficient way. Also, again, I would say the batching of transactions reduces the cost, because if we send transactions one after the other, the gas price will be charged for each transaction. But now, if we combine a bunch of transactions into one single request and then send it, the gas cost gets reduced. So, I would say, like, if we have very complex things like using internal libraries, transactions, and sending. So, yeah, I guess we can just manage. And, also, like, the cost of cross-contract calls, where one contract is calling another contract, it's pretty simple, actually. Why? Because we just use the other smart contract's function or our smart contract function and use getter or setter calls. So, basically, while writing things, we have to see what the function is actually doing, break it down. And then if all the getter functions are there, we make a separate function for all the getter functions and setters, this type of setting that changes the states towards the blockchain. So, I would say this will do a very good job.

In the context of a trading bot interacting with smart contracts, how do you mitigate the risk of front running? The context of a trading bot. Okay. So you know, I would actually mention my experience where for energy trading, he was running a trading bot, which was running every 30 minutes. So what was happening was a smart contract, if we assume it's something that can be thought of as a larger database where so many data is stored. But the problem is if I want to get the data, it's very difficult. So what happens is, whenever a transaction gets processed, we emit an event, okay, that this transaction has been done, and these are the function name or the parameters, and then this is so and so states has been changed. What happens is we can traverse through all those past functions, so the function in this get past events. So based on the block number from and to, we can actually filter through a lot of past events which have already been existed or transacted in the blockchain. And then, based on the filter of the data, we can actually see. Now, again, let's say there's a trading bot which is 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, let's say then we have to do a buy or sell order transaction or process the order that so and so has been matched. So what happens is, like, in the smart contract, it's like business logic, so many rules are written first. If all the rules match, then the transaction will flow. Same thing in the bot also. We have to match all the transactions, all the rules, then only we'll be sending. Why? Because, let's say, if the user's balance is 0, he shouldn't be buying anything. So these are internal checks that we have to use in trading bots so that while sending the transaction, it has already passed all those checks. Once those checks have been passed, then we are good to go and interact with the smart contracts. And, we also have to see that the authorization checks. Why? Because this reduces the 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 this user is having so and so admin rights or whatever rights. So, like, we can actually define based on their user addresses, and then this way we can reduce the risk of front running.

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 it does is whenever a block is cut, something new happens to the blockchain. It, you know, it per block, it tries to read what are the new state changes 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 if the Node.js, or the Web 3 JS thing which we are running in the back end to, you know, that we are trying to filter out all the events that have been done. It reads real-time data and sees, okay. Let's say Alex has sent so and so money to Alan. So it tries, okay, user A has done a transaction to user B. So, basically, how we know is we have done a transaction. We have emitted the event. The Node.js or the Web 3 JS, whatever is running in the back end, it runs and tries to read the live data. It reads, okay, something has happened because the new event is emitted. And this is how it knows because the event is emitted because the transaction is confirmed on the blockchain. Then only the event gets submitted. Once the event is submitted, it gets read by the middle layer, or the back end layer, like, whatever layer we have set the event emitters. And, you know, once it gets read by them, they just show, okay, that okay, now this is the latest data we have because you know? And, this is how we actually see the real-time data gets updated.

What factors would you consider when selecting a consensus mechanism for a private blockchain network? So, there are different kinds of blockchain networks available. It depends on whether we need a permissioned or permissionless network. Now, I'm talking about private. Let's say an organization needs a user's KYC, and different organizations already hold their KYC. Now, let's say Organization 1 asked to get the KYC from Organization 2. The organization cannot simply send it to the network because the KYC data is encrypted and very confidential for any user, and the organization too. This is because a confidential return cannot be sent across to all entities in the network. What it can do is have a private channel where only Organization 2 and Organization 1 are part of that channel. They can simply exchange the data. I'm not talking about authority approvals from the user; assuming it's already having it. So, I'm just talking about why there's a need for a private channel here. A private network is something where there's one centralized person holding the entire control of the network. That's how we call it a private blockchain network. Whatever happens, it can regulate, see why this has happened, so and so forth. It is centrally connected, I would rather say. Now, let's say this was the KYC data. There are multiple other things where, if we have to see, like, where all major businesses think of a blockchain, they think of Corda because they have a central authority and a private network. They can regulate their nodes, how they're operating, and if someone is faulted or not. So, it depends on the business ID also. So, I would say, that's my answer.

Here is a, 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, amount. Let's say it should I it should actually be, you know, you enter 256 here. And I see that, message dot event. Okay. I see that, 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, miss, 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, that this sender has, you know, 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 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, 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. The modifier "only owner" is likely checking if the message sender is the same as the current owner of the contract before allowing the execution of the function. This is done to restrict access to certain functions to only the owner of the contract. However, the potential risk or issue with this implementation is that the owner is a mutable state variable, which means it can be changed at any time. This can lead to unpredictable behavior and potential security risks, as the access control mechanism is based on a variable that can be modified externally. The speaker highlights the issue of maintaining the ownership and access control when the owner can be changed. They explain that if the owner is changed from 0xabc to 0x123, the previous owner (0xabc) will no longer be able to call the function, even if they were previously allowed to do so. The corrected transcript text is: 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. The modifier only owner is likely checking if the message sender is the same as the current owner of the contract before allowing the execution of the function. This is done to restrict access to certain functions to only the owner of the contract. However, the potential risk or issue with this implementation is that the owner is a mutable state variable, which means it can be changed at any time. This can lead to unpredictable behavior and potential security risks, as the access control mechanism is based on a variable that can be modified externally. The speaker highlights the issue of maintaining the ownership and access control when the owner can be changed. They explain that if the owner is changed from 0xabc to 0x123, the previous owner (0xabc) will no longer be able to call the function, even if they were previously allowed to do so.

Discuss an architecture for a scalable p app that involves an Ethereum blockchain packet and a React application, detailing state management of chain storage considerations. Okay, this could be pretty vast. So, now let's say I'm trying to have a decentralized application. Now let's say I have, for example, the 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 three things. So what I'll do is I'll first start writing these smart contracts where for the token launch, for the add-up, okay? Or maybe we already have it. So okay. So my major considerations would be writing smart contracts for staking, unstaking, and calculating rewards. Assuming this has been done, I would be using Hardhat for the testing, deployment, and management purposes, for checking and everything. So once now, parallelly, what we can do is in the front end, once we have the entire blueprint ready, this is how the UI looks like, we can have wallet integrations, connecting to the blockchain where we have Ethereum dot web, maybe MetaMask or Kepler. This is where, once the smart contracts are deployed by Hardhat and once we get their ABIs and contract addresses, we can use both of them, create an instance out of it, use it in the front-end React JS code itself, and then call the back-end functions. So it's a very straightforward thing. And here, detailing the state management is, let's say, if I talk about the UI where the user comes, they enter the amount, and like, obviously, the balance is already 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 the stake function. Now internally in the smart contract, if the user is already having 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 those ten values have been converted to a staked value now. So he'll be having two values, the normal amount and the staked amount. Now, basically, the states have been changed from the front end because we have called and done some transactions. Now, let's say if we also wanted to have off-chain storage considerations where I can either go for the free ones, I can go to PostgreSQL or MongoDB, or live once the once I get the transaction received from the packet, okay, this transaction is successful, I can then call the database and store all the data, whatever I needed. If I needed a paid version, I can go to AWS, use the DynamoDB relational DB, whatever. It actually depends on the requirement. So I would say this is the broader architecture how it will look like. Also, we can have a parallel Node JS application or Next.js application running, which monitors each and everything, what is happening and so on and so forth.

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, we can go to Etherscan.io, and we can see there, you know, for that particular transaction, how many pending transactions are there? What are the gas prices? So, basically, if you know, if we go to the scanner.io, let's say, on the top left of the page, we can see the gas fee, the gas price, and the base fee and everything. Based on that, while deploying the smart contract, we can use those base fee, gas fee, gas price, and in the hardhat configuration, and simply do it. And, also, for the ERC contract, what we can do is, you know, we can use the OpenZeppelin ERC 20 library, where we have to simply call their constructor, which is having name and symbol. Once we do that, we can use their balance, transfer, and so many functions, which are internally built, like allowance, payables. Like, so many functions the ERC 20 contract holds, so we can simply use them, optimize our contract, and deploy it. This way, we can have our own ERC 20 contract. So yeah.