Haci's Debugging Adventures

Merger of AGIX,OCEAN and FETCH Analysis

Sun, 23 Jun 2024 15:31:59 +0100

Disclaimer

I am a token holder of AGIX and SNETs spinoffs. I do not work for SNET or any of their spin offs

Context

In mid March 2024, there was an announcement on the Singularity Net forums which was stating a merger between some of the largest market cap decentralised AI companies, $AGIX, $FETCH and $OCEAN. The merger of these companies aim to accelerate AGI and bring it on a decentralised platform. Regarding the timing this was a great time for all three of the companies with their token value consistently pumping up to 4X over that time period. It seemed logical that a merger of these organisation will definitely get a lot of publicity especially before any hype trains began or ended.

Each company tackled a different vertical which enabled privacy preserving, decentralised agents. So logically it made sense this merger will be great. The teams of all three organisation pushed for this to take place very quickly with only SNET doing a vote. The other organisation stated that this is an executive decision (so much for decentralisation).

The issues

With a merger like this there are a lot of factors to to be taken into consideration which we covered with a lot more detail in the report attached at the end. However a rough overview is as follows.

SNET team being able to vote
Votes not being on chain
Erosion of AGIX holders voting power
SNET’s spinoffs and how will they be weighed
Absensce of the voted parties contributions
Concerns regarding FETCH
Tax concerns
Token allocation

and more

As you can see mentioned above, there is a lot of concern regarding centralisation of the merger.

Voting Concerns

One of the most critical points of contention is the ability of the SNET team to vote. This situation creates a potential conflict of interest and raises questions about the fairness and transparency of the process. In a truly decentralized system, every stakeholder should have an equal say, and the centralization of voting power undermines this principle. Not to take into consideration that the SNET team has a the majority of the tokens. Thus ensuring that they can outvote whatever the community proposes.

On-Chain Voting

The lack of on-chain voting is another major issue. On-chain voting ensures transparency, immutability, and trust in the voting process. The voting mechanism instead was a signature stored with a wallet that has an allocation. These signatures was stored on their platform. Whilst making voting free it is strange that a decentralised crypto first platform refrained from on chain voting to provide the immutability of the votes.

Erosion of AGIX Holders' Voting Power

The merger dilutes the voting power of existing AGIX holders. If the new entity does not adequately account for the contributions and stakes of current AGIX holders. With the dilution of voting it is fair depending on how the tokenomics is agreed upon. However the other parties did not even take their community into consideration regarding the merger. This dilutes SNETs values since they’re merging with a company that doesn’t appreciate their token holders, which is a strong consideration members taken when supporting a token.

SNET’s Spin-offs

Another complex issue is how SNET’s spin-offs will be weighed in the new entity. The contributions and stakes of these spin-offs must be fairly assessed to ensure that their interests are adequately represented in the merged organisation.

Token Allocation

Finally, the allocation of tokens in the new entity are not respective of the performance of the token value nor the value that the companies merge bring. The ratio is as follows. 1:1 $FETCH to $ASI, 1:0.433350 $AGIX to $ASI, 1:0.433226 $OCEAN to $ASI. These token allocation was decided regarding a snapshot where FETCH was performing better than its counterparts in the market, which is not respective of the true value of the asset. This also does not taken into consideration the other values presented in a merger. Such as the team, the products, the philopsophy and the focus to decentralisation and more.

For a more detailed analysis regarding the token allocation view my notebook which does EDA (Exploratory data analysis) regarding the token performance of the tokens.

Conclusion

While the merger of $AGIX, $FETCH, and $OCEAN has the potential to significantly advance AGI on a decentralized platform, it also raises numerous concerns regarding centralization, transparency, and fairness. It is crucial for the involved organizations to address these issues comprehensively and ensure that the merger process is inclusive, transparent, and fair to all stakeholders. Detailed insights and recommendations on these matters are provided in the attached report.

Attachments

0xCASTLE

Sun, 16 Jun 2024 20:46:16 +0100

TL;DR

What is 0xCastle

During Eth London, I overheard a group talking about cryptography and heard them mention 0xCASTLE. I was intrigued because the characters “s,t,l” aren’t hex characters. After hacking for a while, I saw a pamphlet in the smoking area describing 0xCastle. It sounded like a conspiracy about a cryptography event. A weird cryptography event taking place after ETH Berlin.

After recovering from the hackathon a week later, it popped into my mind again. I went to their website and started learning more about it: 0xCASTLE. I noticed that the Cambridge Blockchain Society was sponsoring the event, so I reached out to them since I was with them at the time. After a couple of weeks of back and forth, my accommodation was covered since they were a sponsor of the event. I then arranged my flights five days before the event and flew to Berlin for the last day of ETH Berlin.

ETH Berlin

Half asleep and with no internet, I navigated Berlin to the venue. My time at ETH Berlin was limited, but I saw some familiar faces and met some anon people IRL. It was great! I also had the chance to support a friend’s submission, which was awesome. I scooped up the remaining merch, spoke with Vitalik momentarily, watched the finalists, and then met with the group at the coach. After a grueling two-hour journey trying my best to stay awake, we arrived at Crypto Castle Leipzig. I ran to my sponsored room, which looked like the peasants' corner with a ceiling so low even I had to crouch.

Overview

During the five-day retreat, I met amazing people from around the globe. I was exposed to some of the latest advancements in ZK research, such as optimization in multivariate polynomials using Binius. The castle views were amazing, and I got to understand the inner workings of key cryptography a lot more! I also presented a talk about the current and future research of FHE, giving a thorough overview of where it sits and clearly outlining the novelty it brings. Some people reached out to me afterward, and we had fruitful discussions about where we see the technology going.

As the final days were nearing, I got to learn a lot more about other people’s journeys. I found a lot more peace regarding the specific situation I was in, and I was encouraged to enjoy the journey more. I made amazing friends and got sponsored to go to another conference. I’d be happy to discuss how that happened face to face if our paths ever cross!

HackAThoning

Wed, 27 Mar 2024 20:32:02 +0000

Hackathons

Coming from a cyber security background I always found the name hackathons strange, cyber folks are have our group all nighters and we call them CTFs (Capture the flags). It makes more sense to call CTFs hackathons in my opinion but I digress. Whilst the culture of hackathons are not healthy, with free energy drinks, snacks and ridiculous staying all night culture. It is still great fun and enables individuals to learn a lot in a short amount of time (if done correctly). I’ve been to really bad hackathons and some amazing ones, but a great hackathon ensures there is proper food, support for individuals and a 🚬 area .

Eth Oxford

The fortnight begins at EthOxford I am currently working at a startup where we’re building data analytics tools to web3 companies to provide data driven solutions. The larger goal is to provide full autonomy to DAOs. Check us out on github. So far we’ve built a data analytics to visualise community behaviours within discord servers, we are able to provide data driven insights into community to be able to identify “influencers”. Our aim at this hackathon is to provide integration with github so we can provide the same features via aggregating discord and github data, this will enable us to identify “builders” a developer with strong social presence. Working with github’s API was luckily not problematic however we were confronted with a major problem.

Data pairing

A contingency associated with doing the builder analysis is to have pairing of discord accounts and github accounts. By pairing we can confidently state that these 2 accounts have the same owner. This was proven to be a challenge, since if this information was stored somewhere it will be in a highly unstructured area of the internet. From our analysis on the HomeDao Server we quickly realised that it was a rarity for people to link the github to their discord account. As you can see below.

So from a personal level we need to address if this a technical or a business problem. Never the less we cant solve this fancy problems at a hackathon so instead my team started manually asking people for this information. This is when we realised that most members who are part of the hackathon haven’t joined the discord/hasn’t messaged within the server. This makes our analytics kind of useless since there is little to no value we can equate with no activity. However luckily my team was persistent and we were able to reduce our initial list of 70 github and discord usernames to 25 ish. Another perk of manual data analysis we realised is the cleaning we needed to do. Most people gave us their display names and it there was small information missing from these names too, such as a hidden full stop or Capital letters. Never the less me and my team worked through all of the problems and finally had a working demo.

Judging

The juding experience was interesting we were given a room for our track (social/gaming) and we were told to wait. Our team was talking to other teams and we were asked to present. We presented second a friend of mine did a quick explanation tinkering with Farcaster, it wasn’t a complete submission. Whilst going up to the stage I accidently palmed the drink of someone. It spilt a little bit and I expressed my sorry, later we found out that this individual was the judge and representative of a16z crypto 💀. Our presentation went smoothly and answered 2 questions that came from the judge. My opinion on other individuals works were mixed. There was some clearly talented people, a lot of rushed project, some project that felt like the first apple demo and some projects that blurred what they’ve built in the hackathon with past work.

In the end we didn’t win the track but I thoroughly enjoyed working with the team and meeting people at the hackathon!

FINAL SUBMISSION

ETHGlobal London

Next week was ETHGlobal london During EthOxford I met some individuals who are very interested in FHE, this is a field that I’ve done research and built on before and I truly believe it can revolutionise the world. So for this hackathon I wanted to work on FHEVM which is an EVM application of FHE, I’ve heard of companies like Zama and Fhenix building on this and luckily Fhenix had a bounty for this hackathon. So our team of 4 went to the drawing board to start theorising potential applications. Working with a group of new individuals for the first time was intense. Understanding peoples way of working and aligning on a goal was hard to gauge.

Ideas

FHE changes the mechanism of interacting with systems. Therefore it can be hard to understand where it provides strong utility when building on FHE, taking into consideration the computational overhead drastically restricts its application, but there are many companies working to alleviate this issue. We came finalised on 4 different ideas.

FHE DRM: this is a bounty on zama, so the aim will be to build it on Fhenix then convert the solution to Zama’s FHEVM. However after spending some time on it as a team we didn’t have a strong idea on how to implement this and wether it is feasible to finish it within the 36 hours.
FHE Linear Regression: as mentioned previously there are massive computational overhead, however FHE is in a great position to implement ML, this was a strong contender and had clear application of using healthcare data in a decentralised and anonymous way, however after speaking to the FHEnix team and assessing the computational feasibility we realised that we’d have to wrestle with the Fhenix EVM a lot to able to build and sustain a model. In the future I’d was in strong favour to work on this but at the current stage of the EVM it was not feasible due to computational overhead and the threshold protocol not being implemented.
FHE LP: This was a very interesting idea but in my opinion i think we didn’t spend enough time to iron out the nuiances of what this will require. The order book is problematic since it’s hard to decide what will be encrypted in the LP pool. For example to my understanding if the volume of the LP was encrypted getting quotes will be impossible since the ouput of the rates will be encrpyted. The same issue arrises for price and other elements of a LP.
FHE Gaming: Most gaming computation is low overhead and there’s a strong element of doing computation on private data. There are companies providing this service to the blockchain and On chain gaming has always struggled to find it’s footing, on of the reasons being private state. Some basic computation can be comparison checks, this can enable so much within gaming: think wordle,crossword and battle ships.

BattleFHEps

After having a cigarette with a developer from CryptoKitty, we decided that sticking to the game battleships is feasible and more fun. It’s a timeless classic. Developing it wasn’t to problematic when it came to the smart contracts but there was some tooling on the FHEnix team that didn’t work as expected. For example their gas estimation tooling was incorrect, for large computation for encrypted dataset. This was problematic to identify due to the nature of the problem since the transactions were “successfully failing” it did not help that the testnet and block explorer were also down during some periods of the hackathon.

Working with FHE was fun but identify appropiate usecases for FHEVM was more difficult than anticipated, the technology and research needs to mature a lot more to have more robust applications. The judging was fairly swift, we presented our application to the Fhenix Team, got a bunch of merch. In the end we weren’t succesful with the bounty. But the individual who did get first place worked on a very interesting project, It was a ZK prover within FHEVM. He’s working style really inspired me on how to approach hackathons in the future. He spent, the first 8 hours just writing the pure logic took a nap and spend the remaining time coding it. He definently deserved the prize.

FINAL SUBMISSION

What’s next

I thoroughly enjoy hacking and building small projects, I learn so much and meet amazing people that I will be at more hackathons soon, there was an interesting opportunity to learn more about FHE at a castle in Germany!

EF

Mon, 27 Nov 2023 16:45:59 +0000

What is EF

Entrepreneur First EF (EF), is a incubator/talent investor program that enables individuals to pursue entrepreneurship with reduced risk. The program is split into 2 3 month sections. Form and IC. During “Form” you meet other people on the program, who are in the same boat as you, the talent in the room is exceptional and is the feeling is empowering within the office (At least initially). There are people from a wide range of backgrounds and capabilities and I felt that everyone’s contributions was worth listening to.

Initially within the program I intended on pursuing and building within the FHE space. It was clearly fairly early on that the current paradigms of computation, IE client side encrypting and server side decrypting is a norm that’s really hard to change, especially with the costs associated with FHE. When the program started I teamed up with Milette and whilst I believed the teaming was strong we set very strong goals to achieve that in hindsight was unobtainable, we spent to much time ideating within the trustless space. Which is something that ties heavily with FHE and blockchain technologies. We were unable to come up with a strong trustless need that isn’t already catered to so we ended the team fairly briefly after 4 days of working together.

After doing some desk research in the space I convinced myself that whatever I build within the program must have strong AI appeal. This is due to the LLM craze and funding to the space seemed much easier, since its an easier narrative to sell and it’s technically challenging too. For my next paring I was working with Vlad, and we covered a lot of potential ideas.

Routing engines for specialised models (GPT marketplace didn’t exist at the time). Similar to POE.
We considered providing computation to fine tuning models, and building RAG services.
Output guidance for model generation, IE ensuring the output is JSON compliant
Security guardrails for LLM, i.e prompt injection prevention and observability tooling for usage and generation of models.

However, eventually we ended the pairing due to the constant feeling of getting customer validation for a potential idea, as well as personal differences from work ethic.

At this point I felt fairly lost, I made a lot of commitments to security guard rails for LLMs and it was something I found very fascinating. It catered to my skills very well since I have ML and Cyber Security background so I continued going down the rabbit hole, even writing the code for a research paper. But to no avail it was clear to me at this point that if there was not something I do quickly that my time in EF will be over soon. For the remaining time period of EF I went to Turkiye - Istanbul for Dev connect where I fell back in love with blockchain. In the meantime there was attempts at doing co-founding in the last week. However the narrative within the cohort was fairly secluded and most individuals who weren’t in a team was shilling ideas and requesting other people to join such ideas. This defeated the whole point of co-founding and I felt all discussions that I had within this realm was de-moralising.

In hindsight I should of focussed on what I enjoyed working, I should of stayed within the blockchain space and initiated my discussions as such, I would of had the same issues but atleast I know I’d more more engaged in the realms I enjoy. Also speaking being more open to doing more customer identification and thinking through procedures before reaching out immediately would of been valuable, however this methodology was not favoured by EF where their main mechanism for quantifying success is the number of people who you speak to, which is highly flawed.

What’s next for me? I got a couple jobs in the pipeline, in the meantime I want to travel and I am working on a arbitrage bot , I hope this will keep me engaged for my technical side and I will still be pursuing the startup world, perhaps within an established early stage company or I will be building and release to the wild.

Understanding Federated Learning

Thu, 14 Sep 2023 10:15:57 +0100

What is Federated learning (FL)

FL aims to train NN via utilising locally trained models and aggregating a global model. This can be done via a variety of networking paradigms most notably centralised and decentralised aggregation.

Setup and Initialisation:
- Establish a central server (if centralised) and multiple client devices or nodes.
- Define the machine learning model architecture and hyperparameter.
Data Partitioning:
- Each client retains control of its data locally, ensuring data privacy.
- Clients perform initial preprocessing and data partitioning (e.g. splitting datasets into mini-batches).
Communication Setup:
- Establish secure communication channels between clients and the central server (if centralised).
- Ensure encryption and authentication mechanisms to protect data in transit.
Model Initiation:
- The central server initiates by sending an initial model (often pre-trained) to all clients.

4.5. Model Initiation - Decentralised

local models train on local dataset rather than fine tuning data the initial global model.

Local Model Training:
- Clients perform local model training on their respective datasets using the received model.
- Training can include multiple epochs, gradient descent, and other optimisation techniques. (Having consistency across all client models saves headaches and within a decentralised approach it’s extremely difficult to aggregate different model architectures.)
Model Updates:
- After local training, clients compute model updates (gradients) based on their data.
- These updates are sent securely to the central server or selected peers(decentralised).
Aggregation at the Central Server:
- The central server aggregates the received model updates, typically using techniques like Federated Averaging.
- It updates the global model with the aggregated gradients.

7.5. Aggregation Mechanism - Decentralised training:

Decentralised training requires a consensus mechanism which can aggregate local models in clusters
Use consensus algorithms (e.g. Federated Byzantine Agreement) to agree on a global model.
Ensure that all clients eventually converge to a similar model.

Iterative Process:
- Steps 5-7 are repeated iteratively for a predefined number of rounds or until convergence.
- The model’s performance improves with each round as it learns from diverse data sources.
Model Evaluation and Deployment:
- The final global model is evaluated for performance.
- Once satisfactory, the model can be deployed for inference tasks.

You may of noticed there is no mentioning of sharing biases, this is due to the following reasons:

Data Distribution Variability: In FL, clients have different datasets, which can vary significantly in terms of data distribution, characteristics, and biases. Sharing bias terms directly across clients could lead to models that do not work well to all data sources. Local biases allow models to adapt to the idiosyncrasies of each client’s data but doesn’t convey the same benefits to global models.

Privacy and Security: Federated Learning is designed to maintain data privacy and security. Sharing bias terms could potentially reveal sensitive information about a client’s data. By keeping biases local, it ensures that no client can access or infer another client’s bias information.

Model Flexibility: Local biases enable each client to fine-tune the model according to its specific data. This increases the flexibility of the model and its ability to capture client-specific patterns and nuances. Sharing biases would limit this adaptability.

Reduced Communication Overhead: Sharing bias terms in addition to model weights would increase the communication overhead in Federated Learning, especially in scenarios with a large number of clients. Minimising the data exchanged between clients and the central server is a key efficiency concern.

PET Streaming

Tue, 15 Aug 2023 10:45:36 +0100

What is PET-Streaming

The aim of this project is to provide privacy enchanging technology. Current goals are

Input

Take a stream of cloud data

Process

Anonymise the data

Check if the data within the stream and does appropiate validation - (Does not store) (Catalogue - is verifiied against a list of data assets and data controls)

Output

Send the anonymise data to the end user.

Usecase

The aim is to be able to to take PII data, and provide an api to the dataowner to enable the utilisation of the data by any organisation that they deem fit, without having to worry about the misuse of PII and the end user can ensure the data integrity

Developments to POC

Work with json, CSV or anything else
create an access control panel
Audit record of changes - Store locally back to dataowner
Have a key management system

Second iteration

Create file based interface from storage
Create a different json implementation with stream data
This will require a message broker
Sync all changes to the audit recorder
Fuzzy search for PII identifiers in the key of the data

At all stages

Data Platform End user should have anonymised data
psedo anonymised data
identifiable data
no PII

About

Mon, 14 Aug 2023 12:04:39 +0100

Participated

ETH London - 15th March 2024 - Submission
ETH Oxford - 8th March 2024 - Submission

Supported

ETH Berlin 2024
MoneroKon 2024
Weekly Web3 Workshops
On Chain and OSINT analysis on 2017 Parity Hack - Might Blog Post it

eps1.0_hellofriend.mov

Professional automater, obsessed with data and decentralisation.

As you might have guessed from the title, I am a fan of Mr Robot. Apart from being an amazing show, with outstanding visuals and audio, the plot is very convoluted. The concept of a small talented group having the ability to bring down an ““establishment” has always appealed to me. I guess it is a bastardised version of the American Dream. Regardless, it was mainly because of this show, and other stuff I pursued studying Cyber Security at University, it was within the first month I realised that it isn’t as trivial to replicate the plot.

Coming to the realisation that taking over a country and ruining its economy is too much effort. I was introduced to more cyber-resilient systems, Peer to Peer networks, Distributed computation and more. This is where I was properly introduced into blockchain technologies. Understanding this system may be a lot more valuable in the future made even more doubtful of viability of Mr. Robot V2. Regardless, it’s a good TV show show I recommend that you should definitely watch it (you’ve already stumbled on this page).

How I got into ML, well my interest in cyber mainly pertains to privacy, and ML mainly requires a lot of data. Therefore, I was interested in Privacy Preserving machine learning solutions PPML. The terabytes of high variance data needs to come from somewhere. So my main interest within the ML space is Federated Learning (FL). Where you get the best of both worlds. The automation, flexibility and general value of ML without intruding on the privacy of the masses you need the data from. This should also encourage more people to actively share their data, since in theory the data should never leave their device. So to learn more I jumped in the deep end, for my University research I made ML models using homomorphic encryption. ML or Homomorphic encryption was not covered within the course at all. Regardless I just wanted to learn about stuff that actually interested me, rather than getting a high grade by doing a generic dissertation on networks.

In short, we’re losing to much accuracy when training models, creating models and then encrypting it (inference only) is boring because you already did the deed (using a bunch of peoples data). So I was interested in other avenues, like ZK which has specific applications and Secure multi party computing.