This article was first published on RChain Cooperative - Medium
Greg Meredith and Kayvan Kazeminejad discuss dApp development on RChain through the lens of RCAT.
Greg: As we went out to the stratosphere over the last few podcasts, I wanted to bring it back home to the very practical, which is building applications on top of RChain. Kayvan, I know that you’ve done a lot of work with the RChain Asset Tracker [RCAT] backend. Recently, you and Kent did some bug hunting and I was wondering if you could talk about your adventure — what brought it about and how you guys ended up resolving the matter, and how RCAT fits into the whole ecosystem here.
Kayvan: I think it was version .92 of RNode. We started seeing what we thought was a race condition — basically, intermittent results in testing the RSong and RCAT infrastructure. Without getting into a lot of detail, the way RSong and RCAT persists assets into blockchain — in particular into RChain — and then tracks them through RNode and through RNode APIs — in particular, the deploy API, and finally the propose API — in order to save bandwidth and throughput and be more efficient, we bulk the payloads.
Instead of just doing one asset at a time and storing it on the chain and finalizing it, we stream it and then we bulk it into — depending on the circumstances, depending on what else is going on into anywhere from a handful of assets to a hundred assets — then we do a deploy and a final propose.
As you can imagine, when we start debugging, it’s going to be hard, because you’ve got to iterate through that bulk list to figure out where things went wrong. That’s where a lot of the debugging was coming into the picture. What we were seeing was some of ...
To keep reading, please go to the original article at:
RChain Cooperative - Medium