Jeet Parekh

Yeah. So I'm a computer science graduate from MIMS University in Mumbai. And post my graduation, I joined Accenture as a blockchain developer back in 2018. And I worked on multiple projects of production grade, the first one being an anchor-led invoice financing platform. Here, I was, this was built on R3, and my primary responsibility included the back-end development of the onboarding service and notification service as well as the entire infrastructure management for this project. And this was a project where multiple financial institutions came together, formed a consortium. And whoever had onboarded onto the platform, they gave credit limits to individual vendors, and the vendors then had options to pay their invoices and repay them after some time. This project actually helped them reduce fraudulent activities with the same invoice being financed by different multiple financial institutions. My next project was with a major pharmaceutical company where we built an end-to-end pharmaceutical product check and trace application. So the idea was the end user, the patient being administered with the vaccine, could scan the barcode and get the entire lineage, identify any temperature conditions that were not violated. This was a truly multi-tenant architecture, with different entities on different cloud platforms like AWS and Azure. We used Hyperledger Fabric to build this one. I led the back-end development team as well as the infra team in this particular project. My next project was a grant management system that was built using QLDB, quantum ledger database. It was more of a centralized system that offered all the features of our blockchain network, but a central party was responsible here. And it's actually being currently used by over 2,200,000 people. More recently, I've worked on a high-performance CBDC implementation using R3. This project had its unique challenge with the throughput requirement of around 20,000 transactions per second, and we were able to scale up the entire network and achieve this throughput by incorporating various performance tuning techniques. We used a cluster-based approach, identified the bottleneck was the notary cluster, and divided the entire network into multiple zones, each with its own notary cluster. We used concepts like sharding and even implemented features like online wallets and offline transactions. So, yeah, this was about my experience in blockchain. More recently, I have started expanding my knowledge on AI and ML. At my current company, Uptube, we implemented a retrieval-augmented generation technique that would ingest thousands of pages of PDF to create personalized learning journeys for different users. And we actually were able to reduce the content creation time by almost 90%. And the user engagement has increased up to 80%, which is a very high number in this industry.

So generally, a race condition occurs when multiple entities, or in this particular case, multiple Python microservices, are trying to update the same set of data. Right? So in order to address this, we can use multi-version concurrency control, which is also known as MVCC. So in this case, instead of, let's say, two microservices, where one is trying to update it while the other one is trying to read it. What we do is, when the first one picks up the data, and applies all its processes and tasks instead of updating it directly. It will create a version of its own and then update it. And while it is updating it, if the other service tries to read the same data, it will still be reading the initial version because the first microservice has not committed its changes yet. So as soon as the first service commits the change, the current state of the data is updated to the newer version, and all subsequent reads or writes will happen on this version. Yeah. So I would like to address this situation with MVCC.

So in order to implement data synchronization between Hyperledger Blockchain and Ethereum network, I would generally try and implement a multi-version concurrency control system, where, let's say, while Hyperledger Fabric has picked up a particular set of data that it needs to update, it does not directly override the existing data. Instead, it first takes it, applies the changes, creates a new version out of it, and then applies the changes. And once it has completed all other tasks at the time of commit, it actually pushes the data so that if any other entity or a network is trying to access the same information, they are not reading the previous version until and unless the version is updated, they still have access to the previous version.

So in order to ensure integrity and consistency, we have to follow a set of guidelines that are clearly defined and understood by everyone involved.

So in order to debug a failed transaction in a Hyperledger blockchain network, there are multiple ways to do it. One of the easiest ways would be to debug the logs. In the ledger, all the transactions are recorded, whether or not they're valid or invalid. So one would be to look at the ledger. The second would be to look at the logs. Ideally, you would want to keep a centralized logging system where all the logs of any transactions taking place within the network are generated, and you can inspect the logs to figure out what went wrong. If that's one thing, you can even use some tools like a block explorer that gives you a real-time view of what's going into the blockchain network and what's not going in.

So in order to choose between a RESTful API and RabbitMQ implementation, the most important criteria would be whether or not I want to decouple the two architectures. So let's say if I have a service 1 and service 2, service 1 wants to send the data to service 2. And if you can, if you need a synchronous response and you cannot have any delays, then you would probably want to choose RESTful APIs. But it comes with its own set of drawbacks, that if the service 2 is down, you might not get any response at all. If you want to create some data and the service 2 is down, you would have to implement some mechanisms to ensure that the data is not lost. But in case of a RabbitMQ, a messaging system in between, it would be an asynchronous process where you'd not get the immediate response. You'll have to wait for some time, or depending on the service 2, whether or not it's able to immediately pick it up and process it. But yeah. And the data would not be lost because if the service 2 has not picked it up and not processed it still resides on the queue. And when the service 2 comes back up, it can still have access to all the data, and it can process it.

So this particular code snippet is an error. The fur in the first line, we've created a mock stub. The 2nd line, we're trying to read the state for some key. But in the 3rd line, there's an error that basically, we are checking if error is not equal to nil. We are returning error that we have failed to get the state for the key. But actually, if the data is identified and if there is an error, then we should be checking for error equal to nil. Sorry, my bad. One of the things that I see here is that some key is hard-coded. We are first checking for error not equal to nil. If error is not equal to nil, basically, we are saying that there is some error, and we are unable to fetch the state for the key. And second, we are checking if the value equals nil, which means we did not find any data for this particular key. In that case, also, we are returning that key not found. Else, we are just printing the value for the key. After that, there should be a line to return the value. And ideally, if there is data associated with some key, you should be able to get it.

So this particular piece of code, it first imports the AMQP and then tries to connect to the queue called AMQP local host. And then it executes a function where we are creating a channel within that connection. If there's any error, we're throwing the error, and then the queue name is defined as task queue. The message is called "hello, world." We check that there is such a queue. So it will check that there's a task queue. Then we have a function to send to the queue where we select the queue name as well as the message that we sent in the buffer format. And if everything is successful, we have a log here that the particular message has been sent. And there's a set timeout function after that. So every 0.5 seconds, it's 500 milliseconds. It will try to do the same thing. The potential issue is we don't need to create a channel every single time we want to send a message. I would probably approach it in a way that the channel is created, and I call send to queue.

To upgrade the chain code on a live Hyperledger network, what we need to do is, first, go to the peer and fetch the channel details. And those channel details, ideally, you'd want to fetch the details, and then you need to calculate, basically, first, you write the chain code, convert it into a package. This package is something that we need to get approval from all the different endorsers in the fabric network. So the first step would be to fetch approvals from the different endorsers to upgrade the channel. Once you have collected the signatures from everyone, you take that package. Now you can go to your client library. And once you have all the endorsements, signatures, you submit, increase the sequence of the chain code, upgrade the version of the chain code, and then submit a transaction to the order. The moment the order makes it a part of the block and then distributes it to all the validating peers.

So RabbitMQ has different ways of implementation. So, RabbitMQ basically follows the AMQP, which is the Advanced Message Queuing Protocol. AMQP, basically, has a message exchange that is connected to different queues. And when your consumer wants to send a message, it first sends it to the message exchange. And based on how the message exchange is configured, it will pick the correct queue that it wants to send to. And from this queue, I connected the consumers. The consumers will take the message, process it. And that's how RabbitMQ is implemented. Now there are different ways in which message exchange can be configured. Some of them being fan out, which means the message exchange will send the message to all the queues that it knows. Then there's a topic-based configuration where it will send to the topics or the queues that are basically part of this topic. Then there's a message header, like whatever is specified in the header, it will take the message and send it to that particular queue. And finally, it uses the binding key. So whatever binding key has been selected by the consumer, the message is sent to that particular queue. Now in order to ensure that transactional messages are processed in order, we need to configure it in a first-in, first-out manner. So the messages that are produced first will get consumed first. And once the messages are published in a sequential order, that's how they will be picked up by the consumer. And there won't be any loss in a distributed blockchain environment because if there's a downtime for the consuming service, then the messages keep getting accumulated in the queue. And when that service comes back up, it picks up the message from the queue and then processes it.

If I need to perform a complex join of data from Postgres and MongoDB with a blockchain application, I would probably use an AWS Lambda function. So my Lambda function will have this query, and it will execute the query. Once it gets the data from the database, it will then make the message convertible in a format that can be consumed by the blockchain application. Generally, the blockchain systems are considered to be pretty slow compared to traditional systems. So I would probably not want to keep the burden of doing this complex join of data and any transactional activity as an additional burden on my blockchain application. I would probably want to use a separate service. And we can even use some ETL tools like AWS Glue, or I think the services like AWS Lambda would be the best.