draft: Contributing roadmap #36
Conversation
|
What useful can be done with Rust and testing on Cardano? https://eprint.iacr.org/2023/1762 https://github.com/alexromanov/awesome-blockchain-testing https://github.com/hslatman/awesome-threat-intelligence |
|
Taking action to empower FOSS contributors may continue . . . |
|
collaboration with MD4SG The MD4SG Working Group on Algorithms, Law, and Policy focuses on this complex relationship between algorithms and mechanisms on the one hand and law and policy on the other hand. Some of the topics the group will work on include but are not limited to free speech, content moderation, antitrust, the use of “black box” machine learning models, data-driven algorithms, and decision-support tools. The current theme is AI governance, my input is Su, Larangeira, and Tanaka, “Provably Secure Blockchain Protocols from Distributed Proof-of-Deep-Learning.” A cool thing they talk about is decentralised model training. Why is it cool? Let's go back to the discussion at the ALB working group, the threshold-based regulations. They seem to target the weakness of the technology - as we discussed, AI is very computationally heavy. So the regulator tells OpenAI to report on models they are developing if they exceed some numbers of CPU cycles during the training. Or they ask Amazon to report if someone trains a huge model on their servers. These are expenses for OpenAI and Amazon which end up being taken from the consumers pockets: prices for the API calls, app subscriptions, etc. In a perfect world we could do much better. Decentralised training could mean a market where you can do whatever OpenAI does but on user machines instead of supercomputers. Install a program on your computer, run at night, let someone train a model on your computer - you get crypto rewards. If someone starts making money with the model they trained on the network - you get rewards for the CPU cycles you donated, or maybe they don't so perhaps you get access to the model for free for a while. |
the goal is to feel a productive, impactful, and satisfied developer through contributions to the group.
The driver is to develop the discusstion with @RSoulatIOHK started at
Next steps are to advocate for Developer Experience considerations during discussions, improve Developer Experience through writing documentation, examples that describe the evaluation process, Test-Driven Development as the framework for organisational practices.