System Design: Steem Blockchain ChatGPT Robot

A few days ago, I integrated ChatGPT into the STEEM blockchain, but the original design was flawed. I found that other robot commands (!bing, !thumbup, !price, !info) also had problems, so I took this opportunity to redesign Refactored code and structure. This DApps (ChatGPT robot) is written in JS (Node) and hosted by pm2 manager on a cloud server (VPS Server) .

STEEM Blockchain ChatGPT DApps Design Flaws

Original design:

1. The process (Blockchain) listens to all the posts on the STEEM blockchain , and puts the operations of comments (including !ask commands) that satisfy the conditions into the database.
2. A process (ask) or other command fetches the corresponding records from MySQL, processes them immediately, and then publishes to the STEEM blockchain synchronously in the same process.

There will be a problem here. Indeed, there will be problems with a large number of concurrency. A STEEM account can only post a comment every 3 seconds, so it will be problematic when processing simultaneously at scale. When multiple people call the robot on the STEEM blockchain at the same time, it will cause congestion when the last step is sent to the STEEM blockchain.

The easiest way is to add a Retry process when commenting, but this will increase the overhead and complexity of the process. Also, this may lead to duplication of code for each robot.

New Design and Architecture: STEEM Blockchain ChatGPT DApps

After the redesign, I added a comments process that does only one thing: every 3 seconds, reads the comments that need to be posted from the MySQL table, publishes them and marks them as done.

Here is the overall design of the component:

When the robot finishes processing, for example, when the ask process calls the ChatGPT API to return the result, the comment is stored in the MySQL table instead of directly published to the Steem blockchain. All processed comments (comments successfully posted to the blockchain) will be recorded in the logs log table.

This has several advantages:

• Decoupling component (Decoupling): The blockchain reads the transaction, the “ask” process gets the message and calls ChatGPT, and pushes the answer to the database. “comments” reads comments and publishes them on the blockchain.
• Code reuse: All handling bots share the same code, except for the handling part. For example, “ask” invokes ChatGPT, “thumbup” retrieves a random like GIF, “bing” returns a random wallpaper, etc.
• Reduced errors: Previously, records were only marked as processed after a comment was posted, but this caused a delay that could trigger another round of processing, meaning the same message could be processed multiple times in parallel .

With this design, messages that are fetched are immediately marked as handled, while comments that are about to be published are not affected by this status.

After refactoring, the reliability and usability have been greatly improved. The process run by pm2 manager is shown below.

retry logic/policy

Currently, the system has no retry policy. For example, publishing on the Steem blockchain may trigger errors due to insufficient resource units or network issues, etc. When this happens, we can either re-queue the records to the comment table, or just update the timestamps so they can be fetched later (in first-in-first-out order, so that other new ones can be picked before “retrying” the message information).

During peak hours, ChatGPT on the Free Plan may take a while or even a few minutes to return a response. Currently, the ChatGPT DApp on the Steem blockchain has a timeout of 120 seconds. If it fails, bad JSON may be returned (SyntaxError: Unexpected end of JSON input), and then we have to put the request back into the database (queue) and update the timestamp. After a certain number of retries, we may abort the request and fail it completely.

in conclusion

This paper presents the system design of bots (commands) on the Steem blockchain. We use the database (MySQL) to persist and implement the two purposes of the message queue. If performance is an issue, we may need to consider using a high-performance Message Queue instead of a Database.

The current design overcomes the limitation of publishing 1 comment every 3 seconds on the Steem blockchain and allows multiple bots (Dapps) to process messages simultaneously.

Project Steem Moon!

• You can exchange STEEM/SBD for USDT (TRC-20) through Steem2USDT !
• Sign up for a free STEEM account on SteemYY !

There are a total of 1114 Chinese characters in this article, count it right.

¥ tipping support

Scan the QR code and share this article to WeChat Moments