I did a lot of work on Proof of Service mechanisms this back when I was doing Dawn... Mainly it functions by a chain of signatures from each party in the process, eg, client signs query, intermediary signs witness, provider signs certificate, produces result, signs, sends back via intermediary, who signs witness, and back. every party in the circuit gets a payment for doing this, so when the client gets the certificate, they ack and then send a service cert to the witnesses who then calculate the relevant reward for each party in the loop.
The part that does the antispamming function has to do with diminishing rewards when the client and server are known, by the ledger, to have business dealings. The intermediary also must not have dealings with either side aside from intermediation. If they do, the rewards are reduced in accordance with the amount of dealings between them. This prevents collusion, as at least one mechanism for implementing this.
It just reminds me of how bleeding stupid it is to let witnesses vote for each other. This clearly is collusion, no matter how honestly each witness deals, it's still collusion.
It sounds clever. I still haven't quiet got my head around the architectures/flows of these decentralised cryptographic systems. It's quite a leap from the data analysis work I usually do!
I feel like I need to read some books or watch some tutorials/lectures on it to be honest. Any suggestions?
Well, you, and a few other very smart people ;)
I see what you're saying about the models corresponding to legal processes though - good point. I probably need to familiarise myself with some cryptocurrency systems source code too when I've time.
I'm sure your sacrifice will pay off one way or another! I've only ever worked in C++ to do computer vision work when the Python bindings weren't fast enough... not pleasant!