Blockchain Engineering 2023 - Upvote Token

[InvictusRMC]

Upvoting token. Each user can give away an infinite amount of ❤️ tokens. Content creators are rewarded with ❤️ tokens, boosting their visibility. Content gathering lots of ❤️ will get more attention and go viral. Content creators can see in real-time who is giving them a ❤️ token. The ❤️ token economy design and implementation is your responsibility. Part of your demonstration will be a wipe-based UX implementation which favours viral content. Fraud and manipulation of your token economy such as the Sybil attack can be ignored. Bonus background reading: The like economy: Social buttons and the data-intensive web.

[InvictusRMC]

Some difficulties compiling, fix ASAP!

• Move slot to afternoon
• Next sprint:
  • Look at IPv8: https://py-ipv8.readthedocs.io/en/latest/basics/overlay_tutorial.html
  • Transactions: Create IPv8 overlay, and make first transaction between clients
  • Double press video: like and send token
• Previous work on tokens:
  • Eurotoken.pdf
  • https://github.com/Tribler/trustchain-superapp#digital-euro

GitHub handles to add:

• LeonKempen
• NektariosEvangelou
• BryanHeee
• zhiyongzhu

[LeonKempen]

@InvictusRMC Last week we have created a fork of the project and added our own submodule. Each one of us managed to compile the application and run the new submodule.

For this sprint we have added the following features:

• We have created our own ipv8 community and overlay
• With this overlay it is possible to send a HeartToken to a random peer if there is one on the network
• Added sending a token to a random peer when the video is double tapped.

Currently we have not tested sending tokens with two physical devices yet. However, sending (and receiving) the token did work when one of us used an emulator and someone else joined as a peer.

[InvictusRMC]

Great progress!

Next sprint:

• Have a look at TrustChain: https://github.com/Tribler/kotlin-ipv8/blob/master/doc/TrustChainCommunity.md
• Improve your token to use TrustChain
• Design a way to store your tokens (SQLite)
• How do others verify that my received tokens are valid?

[NektariosEvangelou]

For the second sprint we came up with the following token design and we wanted to check if we are heading in the right direction. We asked @InvictusRMC to provide some insight on the following:

Token data structure:

a. Balance of upvote tokens in the wallets of sender and receiver.

I. The balance of a peer in DeToks is composed of the number of (upvotes received minus number of upvotes given). II. Peers which have posted videos will additionally have a dictionary where the keys are video ids and the values are number of upvotes that video has received from other peers (an idea we had to make recommending viral videos easier).

b. Timestamp GMT (to act as a nonce and prevent replay attacks). c. Identifier of the video which the sender wants to upvote (to be used later to decide which video should go viral). d. Public keys of the sender’s wallet and and the receiver’s wallet’s public key. e. Signature of the sender (the other peers in the network verifies this signature using the sender’s public key).

On the personal trustchains we would like to store:

a. Hashes of previous block which this token would have as a predecessor. b. Sequence number of the block.

In the database we would like to store:

a. Balances of known peers. b. Transactions on the Trustchain network. c. Possibly in the TrustStore, we would set the balance of a peer as the score, as a peer with a lot of upvote tokens contributes significantly to the value of DeToks.

Reply from @InvictusRMC: "My thoughts: I believe you are actually talking about your transactions. Please take notice that these are different things. The transaction is the act of transferring some data, which is the token itself. By using the balance, you might run into concurrency issues. For instance, what happens when the balance is updated during the process of sending the transaction? I like your idea of your balance decreasing when giving away upvotes. It makes upvoting a resource that must be used wisely. It does, however, leave me wondering about incentives. Why would you ever upvote content if this would lead to a decrease in your net worth? These are all things to take into consideration."

[NektariosEvangelou]

@InvictusRMC, for this sprint we have discussed the following things and/or added the following features:

All group members read up on TrustChain. As seen in the previous comment, we have also thought about our token design. We will discuss it further with you in our upcoming meeting. We managed to integrate a start of the TrustChain logic into our community, however, the validation part is not yet done. We managed to add a generic sqldelight database to our upvote community.

Questions:

How can we hook up a block validator to the TrustChain? Both the EuroToken and the Music modules seem to do it differently, but we cannot seem to get either to work.

[InvictusRMC]

See work of other group on simple token:

https://github.com/Tribler/tribler/issues/7311

[LeonKempen]

@InvictusRMC Hereby our update for sprint 3.

This sprint we worked on finishing the token design and trustchain implementation. We made the following decisions regarding this:

For the Trustchain implementation:

• We want to create an open ended proposal block for each video such that every viewer can approve and complete the block when the user upvotes a video. Currently we added the functionallity to create such proposal block on the click of a button on screen, which then can be singed. Later on we expect this block to be received with the torrent of the video.
• We also implemented a daily balance checkpoint block such that we can keep track of total balances easier and it would prevent the network to track back to first transaction block to find the current balance.
• The amount of times a proposal block is signed can later on be used as an indication which video should go viral.

For the Token design:

• We have decided on the following information to be stored in the token: token_id, date, public key of the minter and video_id
• The token id is a value between 0 and 10 and is unique in combination with the date and public key of the minter, more details follow below.
• A user can mint upto 10 tokens a day, such that they do not have to spend something to create a token and to make sure that there is some scarcity in the tokens.
• The limit of 10 tokens is reset everyday, but unminted tokens are not passed over to the next day to prevent token stacking.
• Sent tokens and received tokens are stored in a table. The sent tokens can be used to find better recommendations for the sender. (Incentive to spend tokens)
• Received tokens might be used in an in app store or to trade them for something else of value or possibly be spend to upvote more than 10 videos, altough this is not implemented yet. (Incentive to get tokens and to create videos)

All changes are currently on the master branch. I have created a PR to the trustchain repository but it does not seem to create an APK yet. We look forward to your feedback this afternoon!

As pointers to next sprint we want to do:

• Think about whether we want to use the trustchain for the tokens as well, since the trustchain can function like a db too
• Refactor the videoAdapter.kt file, look into the eurotoken module for inspiration

[InvictusRMC]

Great design ideas!

Next steps:

• Start working on a recommender system.
  • Also have a look at TikTok recommender
  • Use your clever idea of counting signed proposal blocks!
• Flow:
  1. Receive content gossip.
  2. Watch video & like --> seed torrent
  3. All clients crawl the network for popular content.
• Remove bloat introduced by android and use only your community, have a look at dummy nodes.

--> Great content checkin by https://github.com/ChrisSBras/trustchain-superapp/issues/1#issuecomment-1465608449 hacking https://github.com/Tribler/trustchain-superapp/commit/bd8f42daf66ff7b5e1075b031b4e36c167375ff4

[LeonKempen]

@InvictusRMC Hereby the update for this week:

We have implemented 4 ways of recommending videos:

• The most liked video (aka the most signed block)
• A random video (taken from a proposal block)
• On receiving an UpvoteToken from someone, you send 3 videos of your own back to the sender
• You can send a request to (for now) all peers to send you the 5 videos they upload last

Regarding the torrent:

1. let a user seed a torrent/mp4 that (s)he posted
2. a user that double clicks on a video, will start to seed that video/torrent as well

What we did for these 2 stories was:

• find 20 mp4 videos with a creative common license and turn them into torrent files
• when a user clicks the upload video button, one of the 20 torrents is selected to be seeded
• a magnet uri link is created from the torrenthandle that corresponds to the seed
• this magnet uri string is sent to all peers who are online
• once a peer receives this magnet uri, it executes the code for getting the torrentInfo given the magnet string The code for implementing all the above was code that was adapted from the AppGossiper, LiteratureGossiper and the code written by the team "Upload for profit"

The obstacle encountered was: the function call sessionManager.fetchMagnet(magnet, 10) returns null instead of the byte data needed to decode into a torrentInfo object which can be used to download the mp4 video As a result we currently cannot download the mp4 corresponding to a torrent's magnet link which is being seeded

[InvictusRMC]

Great work!

Next sprint

• Work on incentives for content providers as discussed!
• Document your design choice
• Benchmarking? Let two emulators on a laptop communicate directly with sockets: https://stackoverflow.com/questions/59713887/socket-connection-between-two-emulators

Deliverables

• We expect a report documenting your design choice: Example

[LeonKempen]

@InvictusRMC Hereby the update for this week:

Torrent seeding & Incentives for content providers:

• We have fixed the torrent download implementation. We found out that our getMagnetLink() function did not work as it always failed downloading from the magnet link URI. The getMagnetLink function was inspired from the LiteratureGossiper and AppGossiper. We got “inspired” by another groups implementation for downloading torrents, which is at its core an adapter version of the buildTorrentIndex() function.
• We implemented a greedy client approach for users to seed content from other content providers. We have a function called getContentToSeed() which currently gets 5 (this is just a variable which can be changed) random videos posted by other (offline) peers
• For the seeder reward we have implemented the following: When upvoting a video, the user now sends multiple tokens over to the creator of the video. In the tokeninformation we have added the public key of a seeder (currently own key to test with, will later be key of seeder that seeded the most bytes). When receiving these tokens if a video is liked, a subset of these tokens will be sent to the seeder specified in the public key. For this, the creator of the video also creates a RewardBlock on the trustchain, such that other peers can verify whether the creator has rewarderd the seeder. We will add more extensive information regarding the design and implementation in the readme very soon

[InvictusRMC]

Prioritization

• [ ] Fix final merging issues
• [ ] Focus on benchmarking
  • [ ] Networking benchmarks
  • Example thesis with good analysis
• [ ] Write Unit tests
• [ ] Make PR ready before the grading section
• [ ] Readme
  • [ ] Add an explanation on how others can use your code
  • [ ] Add animated GIF to your readme
  • [ ] Add benchmarks

Meetings

• Tuesday 11th at 3 pm next meeting.
• Examination preferably on the morning of Thursday 20th.

[NektariosEvangelou]

@InvictusRMC Hereby the update for this week.

Benchmarking:

• We have integrated Firebase into our project as to benchmark the recommendation part of the application. Whenever the recommendation button is clicked, it will create new recommendtions and will do a specified amount of test runs. These test runs collect information such as:
  • Start time of the benchmark run as a timestamp
  • End time of the benchmark run as a timestamp
  • Maximum amount of recommendations as integer (this variable can be changed)
  • Public key of the recommender
  • Amount of runs to do as integer (this variable can be changed)
  • Time per run, which shows the average of milliseconds each run takes
  • Timings, these are all times in between each of the runs in the form of timestamps
  • Total time the run took in seconds (integer)
• This data will be stored in Firebase. With this collected data we can write a Python script using Matplotlib to generate charts in order for us to give clear overview on the metrics we collected. We benchmarked this part by creating a local pool of peers (consisting of a few emulators and physical devices) and running our tests. This benchmark data still needs to be processed though.
• We checked on Amazon’s Device Farm, and Firebase’s test tools to load-test parts of the application with hundreds of devices. However, these tools unfortunately do not provide what we are looking for and also bring costs with them. That is why we resorted to manually collect the data and do a benchmark locally with ~20 devices comprising of emulators and physical devices.

Previous merge to main:

• We fixed the merging issues.

README:

• We added some more information regarding our design choices and the project structure.

[NektariosEvangelou]

@InvictusRMC Hereby the final (small) update for this week.

Application:

• Fixed some bugs regarding the seeding of torrents

Benchmarking:

• Results available in report

Unit tests:

• Wrote unit tests for the payload package.

Examination:

• Started on the slides for the presentation.

TODO:

• Fix a bug where a peer does not persist a TrustChainBlock created by another peer
• Finalize REPORT and README (app explanation)
• Make PR ready before the grading section
• Finalize presentation

[InvictusRMC]

You have a solid report, guys! Great work.

Minor points:

• Some naming inconsistencies: TrustChain vs trust chain vs trustchain.
• Graph readability can be improved: scale down, bigger font, better labels (change public keys into something more human-readable)
• Move to your module, instead of root dir.

[LeonKempen]

@InvictusRMC Thank you for the review!

We have incorporated the feedback in the report and made some small adjustments and extentions. Currently we are in the process of adding a code coverage badge to the repository. The tests that we have written cover ~18% of the lines in the main package (including the UI code).

The build that you approved passed and produced an APK which can be found here: APK

[InvictusRMC]

Hi guys, great work! Can you also post your slides here?

[LeonKempen]

@InvictusRMC Thank you for your time and the guidance during the course! Below I have attached the slides we had used during the presentation.

DeToks - Upvote Token.pptx