Blockchain Engineering 2023 - token transaction engine

[synctext]

Token transaction engine. Create a lightweight and fast token transaction engine for mobile devices. Your engine should be able to process 1000 transactions per second with standard 4G connectivity. Record these transactions within a simple SQLite backend. Realise simple primitives such as send/receive token primitives. Required background reading: ConTrib: Universal and Decentralized Accounting in Shared-Resource Systems.

[synctext]

Not yet read the required background reading. @kandrio checked out the superapp, confused about the modules. Also @AkiSchmatzler

• Discussed 20 or 21 April final exam hour.
• Prior work around transaction engine:
  • digital Euro engine
  • Another digital Euro in trustchain-superapp
• Brainstorm on final requirements {tentative} final project goal: how to test the success of your transaction engine? Demonstrate with a 1000 transaction testing workload ("test button"). Print on-screen total transaction testing duration. What is the impact on the CPU / IO / Network when running? What datastructure do you use?
• next sprint goal: create transaction [example trustchain docs], sign with private key, and transfer to another phone using overlay. Python IPv8 overlay examples and tutorial
• Please put an update on your progress by all 5 members on your issue. Weekly update.

[AkiSchmatzler]

meeting with @kandrio , @mehulbhuradia , and myself

• trying to compile the skeleton in Android Studio
• do we need to care about signing in users to the network?
• look at the example trustchain docs linked previously --> every block contains exactly one transaction
• TrustChainCommunity based transactions --> use of proposal block and agreement block for the transaction (see doc) (we have to see if this is feasible for our 1000 transactions per second requirement, but it sounds like a good idea to have transaction be secure and avoid fraud (see detailed description below)

transaction possible implementation

from the example trustchain docs

Initiator creates a proposal halfBlock, signs it with his private key, creates the wrapper halfBlockBroadcast that contains the proposal block. He sends the broadcast to everyone. The receiver (the one which the transaction is intended for) creates an agreement block (AgreementHalfBlock), they sign it. Then, they put the proposal and the ageeement in a block (halfBlockPair) (which represents the completed transaction) and broadcast it to the network (halfBlockPairBroadcast message). The fact that everyone in the network is aware of every step of the transaction (broadcast of proposal and agreement) assures its integrity.

[synctext]

• Do you have the experience to make a get-it-right the first time design? Please no analysis paralysis, just dive in and make initial throw-away code.
• ToDo: everybody has some initial Kotlin code next appointment
• Prior sprint goal: create transaction [example trustchain docs], sign with private key, and transfer to another phone using overlay. Python IPv8 overlay examples and tutorial
• Upcoming sprint goal: bypass databases, in-memory only as a starting point, create 1000 transaction with same sender, same receiver, and record time duration (e.g. performance analysis).
• Nobody has dived into the Kotlin level yet
• @mehulbhuradia "implement Trustchain inside the Decentral TikTok app and integrate with the other teams"

[AkiSchmatzler]

this link contains all the stuff we need to create our community and send our messages over the network : overlay kotlin ipv8

[kandrio]

First Iteration on Transaction Engine

@luukvancampen mainly got his hands dirty with the code in the weekend. At the current state, our app is able to:

1. Present a list with all the peers in the community.
2. Allow the user to choose one peer and send a transaction proposal to that peer
3. Allow the user to receive a transaction proposal (through a pop-up) and confirm it through the click of a button.

NOTE: It seems that step 2 (sending of proposals) does not work consistently. We noticed that in some cases, the sender sends a proposal and no pop-up shows up in the receiver's device. We have been trying to debug this for hours, but no solution has been found yet. We could use some feedback on if this is expected and how to tackle it.

Development repo: https://github.com/luukvancampen/blockchain-engineering

Here is how the main app looks like currently:

[synctext]

Significant experience with @luukvancampen, the "1000" button is exactly what is needed. Just a bit worried that we don't have 5 working developers. Bonus point: fix the tutorial or expand with details within a Pull Request. Code for binary transfer testing (part of the digital Euro): with lost packet reporting Updated digital Euro and packet loss report and try out those IPv8 improvement PRs Everybody was a bit stuck, try to get 3 emulators to talk to each other. Reliable foundations for future sprints.

[kandrio]

Next internal meeting: Wednesday, March 8th at 17:00

To-do

Here are the next tasks we want to achieve, along with the developers that own them:

1. make 2 emulators communicate with each other: @tudatt
2. list in the application the bootstrap servers (if not bootstrap servers shown as green, then the app is not properly connected and an informative error should appear) @AkiSchmatzler
3. check the PR the professor sent us and try to initialize the community as shown in the PR (https://github.com/ChrisSBras/trustchain-superapp/pull/4/files) @mehulbhuradia
4. make 1000 transactions a second work using the new PR that the professor sent @luukvancampen
5. find out why we get a UniquenessConstaint error sometimes when the receiver tries to insert an incoming transaction into their SQLite database. @kandrio
   • ANSWER: It turns out that this error shouldn't bother us too much. The root cause of the error is that, whenever we send a transaction, we proadcast it in the network, and each node shares it with their peers. As a result, the receiver might receive the transaction multiple times and try to add it multiple times in the SQLite database as well, hence the Uniqueness error.
6. build the "confirm a proposal" functionality @kandrio

[kandrio]

Show Bootstrap Servers

I'll use this comment to expose my progress on extending the Detoks app to show the list of connected bootstrap servers.

How to find the list of bootstrap servers

Here's the piece of code that loads a List of the IPv4Addresses of the bootstrap servers into bootstrap_servers:

import nl.tudelft.ipv8.Community

val bootstrap_servers = Community.DEFAULT_ADDRESSES

Actually, DEFAULT_ADDRESSES looks like this:

DEFAULT_ADDRESSES: List<IPv4Address> = listOf(
    // Dispersy
    // Address("130.161.119.206", 6421),
    // ...
    // IPv8
    // Address("131.180.27.161", 6521),
    // ...
    // py-ipv8 + LibNaCL
    IPv4Address("131.180.27.161", 6427),
    // kotlin-ipv8
    IPv4Address("131.180.27.188", 1337),
    IPv4Address("131.180.27.187", 1337)
)

Indeed, if we take a look at the debug UI feature (uses the code from above) of the superapp, we can verify that the only addresses that are shown are the ones that are uncommented in DEFAULT_ADDRESSES:

We want to show something similar in the Detoks app as well.

TO BE CONTINUED: For further updates, see the following comment by @AkiSchmatzler who took over this effort:

• https://github.com/Tribler/tribler/issues/7293#issuecomment-1465226407

[kandrio]

Confirm a Proposal

Current Situation

Currently, the following happens:

• In the UI, there is a button to confirm an incoming proposal.
• When clicking on the button, an Agreement block is created and sent.
• The button and the transaction doesn't disappear after confirmation.
• If the user clicks on the "confirm" button again, then the application errors out.

End Goal

We'll consider this effort successful if:

1. [X] The incoming Proposal dissapears from the UI of the receiver once the user clicks on the CONFIRM button.
2. [ ] The user that created the Proposal gets notified that it has been accepted by the receiver.

Solution

The createAgreement API function

In order to implement the functionality described in goal [1], we created the createAgreement API function that does the following:

1. Removes the confirmed Proposal from the local proposals database (contains all incoming un-confirmed Proposals)
2. Notifies the proposalAdapter that the proposals ArrayList is updated (so that the confirmed proposal dissappears from the UI)
3. Creates and sends an Agreement block to the sender of the Proposal, using the createAgreementBlock API function of the ipv8 library.

Here's how the createAgreement API function looks like so far...

private fun createAgreement(block: TrustChainBlock, proposalAdapter: ProposalAdapter) {
    for (i in proposals.indices) {
        if (proposals[i].block == block) {
            proposals.removeAt(i)
            proposalAdapter.notifyItemRemoved(i)
            break
        }
    }
    // Get a reference to the TrustChain community
    val trustchain = IPv8Android.getInstance().getOverlay<TrustChainCommunity>()!!
    // Create an Agreement Block
    trustchain.createAgreementBlock(block, mapOf<Any?, Any?>())
}

[AkiSchmatzler]

about the bootstrap servers

In the bootstrap-servers branch of our development repo, I added a button bootsrap_servers, which when pressed opens a popup window showing the bootsrap servers :

[update] the popup now also shows the walkable addresses, the WAN and the LAN addresses. There are some issues with showing the bootstrap servers as up or down --> to discuss in next meeting

[synctext]

• Use the merged basic wallet and token:https://github.com/Tribler/trustchain-superapp/pull/136
  • make it complete if needed
  • 1000 Tx button needs to work
  • Token format suggestion: https://github.com/KoningR/eurotoken/blob/main/src/main/kotlin/Token.kt#L27
  • trustchain is for transaction recording, usable for token transfer and recording???
• How to do 1000 transactions per second, understand performance and fix bottleneck issues
  • Example performance analysis using flame graphs. Work from my glory days with Netflix co-author.
  • Grand final figure; example, interactive: https://queue.acm.org/downloads/2016/Gregg4.svg (Figure 8 in https://github.com/Tribler/tribler/files/10930457/MSc_final.27.pdf)
• framegraph for transaction engine (from fast to slow Tx/s)
  • unencrypted Basic block creation with the same content and the same addresses (trustchain-only)
  • unencrypted Basic block creation with the random content and random addresses
  • random blocks with signature
  • signed block creation and in-memory storage
  • signed block creation and permament storage
  • IPv8 stack call involvement, no networking
  • IPv8 stack call involvement, local networking, same device transfer
  • IPv8 stack call involvement, global networking, Full internet transfer overhead and latency
  • block transfer and also Trustchain counterparty signature (e.g. halfblock stuff)
• Required to show awareness of CPU time, wall time, and IO-contained workloads. Or determine what is the bottleneck when running TXEngine fully? CPU, time, or IO?
• What is a good balance between repeatable performance analysis and identification of issues. versus fixing it :mechanic:
• Python IPv8 documentation
• Solid progress. Nice bootstrap node inclusion.
• Advise to use dummy node concept. Not a bunch of emulators which eat all memory and CPU. Basically you use a single IPv8 community in cmdline mode. Then you can spawn a lot of nodes from Kotlin easily with low overhead.

[luukvancampen]

I made sure that the "1000" button works. It sends 1000 proposals to the specified peer and the peer signs them. The sender of the proposals then shows in the app how many agreements it has received and to what proposals the agreements are, so we can do basic packet drop detection. All proposals are assigned a number from 0 up until 999 in order to count received agreements. Each "benchmark run" get its own UUID so we do not accidentally count an agreement for the wrong benchmark.

[luukvancampen]

We will have an optional meeting saturday at 13:00. The next meeting will be monday at 17:00. Both meetings will be online.

Deadlines for monday

• Mehul: fix no peers on own TrustChain community; IPV8 dummy node running; when done, help Luuk.
• Luuk: 1000 tx button works to benchmark the other groups token and record it to trustchain.
• Kostas, Andy, Aki: have five functions that each perform one of the tasks described in the bullet list (the first five); also flamegraph metrics.

[tudatt]

Progress last sprint cycle:

Andrei (tudatt):

1. Implemented a "dummy node" in Kotlin, as LightweightTxAppKt that can be run seamlessly in the terminal
2. Added TransactionEngine API V1 and its implementation TransactionEngineImpl that can be extended by any Community, so it can benefit from sendTransaction functionality
3. Implemented functionality for sending encrypted/unencrypted blocks to specific/random peers in the LightweightTxApp using TokenTransactionEngine.

[kandrio]

Progress last sprint cycle:

Kostas (kandrio):

1. Worked on top of @tudatt's "dummy node" implementation and managed to make peers send basic messages to one another.
2. Integrated our progress with the upstream master branch.

[mehulbhuradia]

Progress last sprint cycle:

Mehul(mehulbhuradia):

1. Managed to get the python dummy nodes running but discarded the idea as @tudatt figured out a way to have them in kotlin and this allowed them to reuse existing code.
2. Worked on top of @tudatt's and @kandrio's implementation of the dummy nodes and the TransactionEngine adding the functionality to receive incoming messages and process them.

[AkiSchmatzler]

progress last week (@AkiSchmatzler ):

• Research about flazmegraphs to profile our code, usage of this repo to set up flamegraph generation based on CPU traces from an Android emulator. Had to contact the creator of the repository to resolve some compilation problems.

• trying to profile with flamegraphs the progress of the dummy nodes --> still to finish as there were some compatibility issues yet to resolve, but should be done in the next day.

  Example flamegraph trace : Since the generated image are SVGs, we can zoom in to see further details for each running thread.

[luukvancampen]

Luuks progress:

• The other groups transaction engine now stores its blocks in TrustChain. It still works with their basic token object. https://developer.android.com/studio/run/emulator-networking

[synctext]

• performance analysis on a single laptop
  • https://stackoverflow.com/questions/59713887/socket-connection-between-two-emulators
  • Flame graph and 1000 signature requests (remote party does blind sign, and immediate return)
  • no big latency or networking issue. zero congestion control, zero flow control :astonished:
• Concrete deliverables discussed
  • transaction API (append only, or also search and read-random)
  • flame graph analysis with the 1000 transactions (as discussed at length above)
• Question: emulator (Arm emulator on x86 it seems) or dummy node (cmdline Kotlin x86 native) or GUI results inside the DeTox app (real ARM performance).
  • support the 1000 transaction test button (various tests, with {no} crypto, {no} IPv8, {no} networking). Single test results screen
  • plus flame graphs from either emulator or dummy nodes
  • Growth factor, cost of storing 50 GBytes in your wallet and adding 1 more Trustchain block.
• draft PR for next week and review to @OrestisKan

[mehulbhuradia]

Tasks going forward: (meeting on 25/3/23)

1. Create the transaction api using code from kandrio-dummy and other-group-progress
2. Create a pr for the api
3. Create flamegraphs
4. Add UI for benchmarking
5. Extend the API to search and view the blocks?

[kandrio]

Progress last sprint cycle:

Kostas (kandrio):

1. Created our first PR that introduces our TransactionEngine API and our LightweightTxApp:
   • https://github.com/Tribler/trustchain-superapp/pull/145
2. Addressed review comments.
3. Created review branch with improvements:
   • https://github.com/tudatt/trustchain-superapp/tree/kandrio-introduce-transactions-api-rev
4. Waiting for @OrestisKan's follow-up review comments

[tudatt]

Progress last sprint cycle:

Andrei (tudatt): branch benchmark:

• created TransactionEngineBenchmark class which is to be used for all benchamrk workloads. Its responsibility is to set up benchmarking test cases and then evaluate TokenTransactionEngine's sendTransaction functionality called with various parameters
• moved functions designed by @mehulbhuradia and @luukvancampen in the TransactionEngineBenchmark class and added a few myself.
• you can see an example of how an app can call the benchmark functions in LightweightTxApp.kt

Questions: Right now we are only sending the block object TrustchainBlock because of the convenience of using the Builder. Should we consider creating our own, even simpler block?

[AkiSchmatzler]

Progress last sprint cycle. We now have the falemgraphs for :

• unencryptedBasicSameContent bloks
• unencryptedBasicRandom blocks
• unencryptedRandomSigned blocks

We can now identify bottlenecks in those functions. The call to functions that have some pseudo-randomness in them seems to be a bottleneck at the moment. Example :

unencrypted Random Signed

we can see thazt our unencryptedRandomSigned function is mostly bottlenecked by the nextBytes() function. In the future, we will change the funcrtion accordingly so as to use another faster function.

[mehulbhuradia]

Progress last sprint cycle:

Mehul(mehulbhuradia):

1. Designed the functions for the IPv8 layers in the flamegraph.
2. Currently redesigning the message handlers to echo messages, these echo messages will be used to record the time taken for the blocks to be recieved and the number of packets lost.

[luukvancampen]

Luuks progress:

1. created functions for doing the first layers of benchmarking
2. created UI for benchmakring and made sure ui can be used to run the actual benchmarks.
3. benchmarking for actual TrustChain halfblock sending and getting proposal back is almost working.

[synctext]

• learnings: taking ownership of the entire process :bulb:
• [x] big milestone: running .APK on your issue
• [X] working nanosecond benchmarking test
• [ ] Rebase and polish your PR. get a V1 prototype PR accepted. Do not hijack the GUI, add button
• [ ] Some magic networking and benchmarking
• Example of great performance analysis at 6-levels of a protocol stack {raw sockets, IPv8-Kotlin+EVA}
• [ ] Required: add 1-section of documentation in readme.md format as with all Superapp PR projects by students:
  • https://github.com/Tribler/trustchain-superapp#peerchat
  • https://github.com/Tribler/trustchain-superapp#digital-euro
  • https://github.com/Tribler/trustchain-superapp#ai-trading-bot
  • https://github.com/Tribler/trustchain-superapp#luxury-socialism
  • https://github.com/Tribler/trustchain-superapp#freedom-of-computing-app
• [ ] Add animated .GIF to your readme.md documentation
• [ ] Final Flamegraph + documentation: only few sentences in seperate section with example picture + pointer to your script directory.

[luukvancampen]

Unpolished APK: https://luukvancampen.stackstorage.com/s/1RzuNuFYpzLYGrQH

The first few steps of benchmarking can be done and it shows the time in nanoseconds it took. When pressing the 1000 button for a peer, it starts a 1000 trustchain transaction benchmark. There are some bugs in that which I will resolve. You can also create a single transaction with a peer, which the other peer then has to confirm.

[AkiSchmatzler]

about the flamegraphs: performance analysis

for signed permanently blocks, time is equally divided between building the block and storing it in storage, there is not much to optimize here, except if we would try and rewrite the function from the Trustchain to not use StringBuffer.append(), as it seems to be the biggest bottleneck. For the SQL storage, the getLatestQuery() call seems to be the biggest bottleneck. (same goes for signed blocks that are not permanently stored).

--> todo: further analysis and write the results in the report, which needs to be linked in the readme

[luukvancampen]

Luuk's progress:

• made UI for benchmarking the non-ipv8 steps. Graphs are generated for time per block, user is able to choose how many blocks to generate or choose an amount of time to run the benchmark for.
• Also possible to press a button to generate a comparison graph of the different IPV8 steps. Links to huge GIFs:
• https://luukvancampen.stackstorage.com/s/iUDdTTgUNdR7R3QF
• https://luukvancampen.stackstorage.com/s/FfrYDFm96AWSn6WJ

Links to original video's:

• https://luukvancampen.stackstorage.com/s/JExw3LsQqxOSNGpw
• https://luukvancampen.stackstorage.com/s/Ud398UiZOGzpyAAT

Link to APK:

• https://luukvancampen.stackstorage.com/s/1RzuNuFYpzLYGrQH

[kandrio]

Progress last sprint cycle:

Kostas (kandrio):

1. Addressed review comments for our 1st PR that introduces our TransactionEngine API and our LightweightTxApp:
   • https://github.com/Tribler/trustchain-superapp/pull/145
   • Waiting for @OrestisKan's follow-up review comments
2. 2nd PR underway that will introduce our entire backend
   • Will have it ready by Saturday 08/04/23

[synctext]

• Very happy with this teams progress
• please give me WOW-factor reviewed PR and readme.md documentation text
• 99.6 MByte .GIF demo, this is an absolute smashing size record :boom:
• Asked about software development methodology used by this team
  • initially dirty throw away code
  • clarified the problem
  • ready for a base design and expanding
  • now transitioned to a PR methodology
• questions have you ever written down MUST HAVE and SHOULD have requirements?
  • in hindsight, writing down a few requirements at early stage would be definitely helped
  • turned into a weekly negotiation process around features, results, and code directions
  • Never asked the golden question: "what is your role", professor, course grader, or problem owner?
• currently you need a verbal tutorial from the original developer to understand the performance graph with blocks, ms wall time or cpu time? etc.
• almost ready for grading, pressing info button does an instant crash :bug:
• lesson learned: performance analysis or simple testing of networking might be even more important then transaction engine speeds.

[InvictusRMC]

Hi team, can you please address the email that group II sent to you? Thanks!

[kandrio]

@InvictusRMC at what email did they send it?

[InvictusRMC]

@InvictusRMC at what email did they send it?

@kandrio apparently they only contacted @AkiSchmatzler on aki.schmatzler@gmail.com.

[AkiSchmatzler]

@InvictusRMC at what email did they send it?

@kandrio apparently they only contacted @AkiSchmatzler on aki.schmatzler@gmail.com.

I answered the group earlier today w the method i followed; I told them to get back to me if they still any further issues

[luukvancampen]

Final APK of this course:

• https://luukvancampen.stackstorage.com/s/1RzuNuFYpzLYGrQH

Readme:

• https://github.com/tudatt/trustchain-superapp/blob/kandrio-other-group-progress/detoks/README.md

Pull request:

• https://github.com/Tribler/trustchain-superapp/pull/154

[synctext]

• the APK works! :balloon:
• ability to understand instructions on 1st level Readme and 2nd level
• Could not find the button :-) Benchmark "Run Benchmark" button is full-width of the screen, no shadows
• Could not find the button II :-) selecting a benchmark, then press compare, not autostarting, press "run benchmark" would be intuitive.
• Could not find the datapoints :-) Runs 3 tests, draws 3 datapoints, and paints a straight line through them.
• Bonus for the flamegraph! (https://github.com/brendangregg/FlameGraph)
• Running trustchain benchmark: 56654 without a unit. Waiting a while without any visual clues that apk was working hard.
• 1.8056E-12 of payload bandwidth (1k blocks test) bug?
• Network undefined in Readme. Two phones in same room? Two emulators talking across the world?
• @luukvancampen IPv8 looks nice from the documentation and API. You get your first code running. Then the disappointment kicks in when you use real networking. Reliability is too low. It just needs to work, that UDP stuff.
  • Boost for the NAT puncturing research
• Flame graphs are generated by manually processing on a dev machine the CPU debug files, created by ??debug class??