P Sai Lakshman

My name is Sai Lakshman, and I'm working in Marine Intelligence as a senior software engineer, and I have around 7 years of experience in blockchain technology. And all these 7 years, I have been working with the blockchain technology on various platforms like hyperledger fabric mainly and Polygon. I also have a minimal experience in Quorum technology. My major contributions in the 7 years of experience are that I got a chance to work with some of the state governments and also the Indian national government. As we were technical partners to some other companies in my previous experiences. And I have a responsibility under my roles and responsibilities for setting up networks in hybrid Ethereum private networks or the Quorum networks across my 7 years of journey. I'm also part of writing the same codes or smart contracts. I have written some APIs which can communicate with the underlying blockchain layer, and also provide API endpoints to the necessary development teams so that they can integrate respectively according to the use cases. I have a little experience of setting up the hyperledger fabric network in a distributed environment on using AWS and also in-house servers for government blockchains.

So while getting the risk conditions, as you know, that the resources are being tightly coupled with multiple microservices. We can handle this by halting one of the microservices if it's not urgent or if it's a blockchain transaction, in which case we want to handle multiple things. We can use some of those and all that stuff to handle the risk conditions.

When designing microservices that interact, the key considerations are assuming that the Docker containers are never down when the microservices are communicating with the blockchain nodes, and also the security while communicating all the transport layer security. So all the communications between the containers or the nodes with microservices has to be secured in a way by using certificates. That is one consideration which I would take. And the second consideration I would take is making sure that the Docker nodes are not going down. Even if it does go down, you should have all the backup of the node data, whatever is there in that, and store the data in the respective volumes of the Docker and the containers, and restart the Docker automatically. And in that time, if there is a communication happening from the microservice, make sure that you record the transaction. And once the service is up, you retrigger the transaction.

What would be the best strategy to handle data synchronization between the hybrid blockchain and public Ethereum network? So by understanding of the blockchains, right, so the data synchronization between a hyperledger private blockchain and a public Ethereum network. So we can have one interface layer called the synchronization layer where we get the data, and if it is my understanding about the question is correct. Right? So which we are looking for the interoperability of the question, interoperability of the blockchains. So in that case, I would write an interface layer of the data synchronization layer between Hyperledger and the public Ethereum network. Once, because in the Hyperledger private blockchain, once we have control within the network setup, whereas in the public Ethereum network, we may not have. Right? But if we are looking at Hyperledger as a private blockchain and the public Ethereum network as separate entities, there are two individual items. Right? So in that case, the data synchronization by default happens at the application layer. We can take care of the data synchronization because once it goes to the chain code level or the smart contract level, it's not in the hands of an application developer or it's not in the hands of the application directly. It's in the hands of the blockchain. So what I would suggest is that the data synchronization, whichever data goes first or which data should go next, has to be clearly thought out and put in the application layer or the API layer, just the layer before the smart contract layer. The same goes for the Ethereum network as well.

In Node.js, we integrate with the Hyperledger Fabric for transaction validation, which is a three-way process, unlike a traditional two-way process. It's a three-way process execute order to validate. So in Node.js, we can check because Hyperledger Fabric uses the Fabric SDK. For every transaction, we get an output from the chain code SDK saying that the transaction is successful with the transaction ID and the transaction hash. Based on that, we can integrate the Node.js based service with the Fabric SDK, keeping the Fabric SDK as a medium layer, where the Fabric SDK based on the configurations can communicate to the chain code layers. Thank you.

This is a blockchain based authentication system. How would you ensure secure communications between AWS hosted microservices? So, secure communication between AWS hosted microservices can happen in two ways. The blockchain network, whichever network we set up, has to be completely secured using transport layer security, with TLS certificates, and a certification authority or membership service products. We can set up and generate certificates according to our use case and also for communication between microservices. Like, we can say that if the services are coming from a specific certificate or endpoint, then we can take it as an authenticated request, or we can put it as a fake request or unauthorized request.

Given a node this application that utilizes RabbitMQ for handling message queues. A certain message is not being processed by the worker service. Below is a simplified code snippet where the message is published. Can you point out any potential issues that could be preventing the message from being received? So Should not create channel. Okay. We are creating a channel. Okay. Channel. Yeah. Where is the task queue messages? Hello, brother. Okay. Just try not to send a queue. So and so is sent. What if send queue fails? So I think, the answer would be if the sending to queue itself is failed, I think we are not logging that. So that would be one problem, what I see, because that is channel dot sent to queue of q comma dot from message, but in the same way, if we can handle that error handling in that way so that we can directly check it. We are assuming that, the center queue works always faster. I mean, always correct. So it may not be the case. So that's one thing which I see.

Require balances of message not sent. When we get the transfer amount, exit's balance is because the balance of that sender or the one who is initiating the transaction is less than the value it has. So, basically, transfer balance because, for example, if you assume that I have 100 rupees and I'm planning to transfer 200 rupees, which is so that's when the transfer amount exceeds the balance. Right? So to set to issue I mean to solve this issue, we can add a check saying that if the balances of message center, which is 100, is less than or equal to the value we are transferring. So, basically, it has to be less than or equal to instead of greater than or equal to. If I'm correct. The transfer value is 100, which is less than or equal to 100, but the transfer value is 200, which is greater than 100.

How do you scale Python based blockchain nodes to handle massive concurrent operations? Excuse me. Click on these blockchain nodes to handle massive concurrent rewrite operations. Invest blockchain nodes to handle as a concurrently. Right? I would assume horizontally or vertically is called the Python based nodes, blockchain nodes, or the blockchain microservices, and put a load balancer in front of it and try to execute the multiple operations on Python based blocks and nodes. I'm not sure about this answer. Thank you.

I would use Kubernetes management or Docker Swarm to manage and operate multiple Docker containers. I would definitely go with Kubernetes. If Kubernetes is not an option, then the next option we have is Docker Swarm overlay networks. We can use that and we can orchestrate multiple Docker containers in different environments.

To troubleshoot and receive with the denial of service that act on blockchain system developed on AWS, by setting up a firewall and taking care of all the ingress rules and the egress rules by maintaining a distributed denial of service attack and also assuming a time out on the API layer or the application layer. So putting up the rate limiting and time out options, we can use that and we can stop the DDoS.