I suppose, in this case you could use the time since invalidation as your input. The downside is that changes in the source aren't immediately reflected in the rendered output, especially for infrequently updated pages.
2,494 karma · joined March 1, 2011
I suppose, in this case you could use the time since invalidation as your input. The downside is that changes in the source aren't immediately reflected in the rendered output, especially for infrequently updated pages.
That's easy. You just need to design a combinational circuit that verifies that a particular list of nodes forms a cycle.
> How much memory would that take for a billion node graph?
Naively, a lot. Thinking about it, way too much memory to be in any way practical.
However, there may be a good way to solve it with an incremental solver or, instead of materialising the graph, you could encode the siphash function in the sat solver. Then it would use much less memory.
If that works well though, it would compromise the original goal of the project.
So true.
> so half an order of magnitude
Almost 70% of an order of magnitude.
[1] https://www.backblaze.com/blog/vault-cloud-storage-architect...
Compile your test suite with -fsanitize=undefined.
Ripple relies on a common shared ledger, which is a distributed database storing information about all Ripple accounts. The network is "managed by a network of independent validating servers that constantly compare their transaction records."
I don't think any system that relies on a global ledger is workable for micropayments like this.
Edit: I spoke too soon, Ripple is more complicated than I thought. It is somewhat like Ripple.
Regarding incentivization, looking at the literature, you can split existing incentive schemes into two camps, local and global. Tit-for-tat would be an example of a local scheme, currency based systems would be global.
Neither of these types of scheme really work, with local schemes, you have no way to use accrued reputation with new nodes. Global schemes require too much coordination and overhead to be suitable for small 'transactions'.
As I understand it, IPFS deals with the problem by having a local scheme, but with a get out clause. If you want something you may have to do work on behalf of the node you want something from, but that work should be easier if you have a good reputation with other nodes in the network.
Under my proposed system, nodes keep track of how much they are in debt or in credit with the nodes that they are in contact with. The amount that you can go into debt with another node is limited to 1% of the amount of useful data that you have transferred to that node. (This way, if a node terminates a connection whilst it is in debt to another node, that loss, amortized over the useful data that you have received is very small). Nodes are incentivized keep connections open, since short lived connections have very tight reins on how much debt/credit can be accrued.
As this stands, this doesn't solve the problem. It's entirely local and there's no way to initiate connections since nodes, by default, don't trust each other.
The solution is two-fold: credit transfer and proof of work. I have designed a protocol that allows nodes to transfer credit to cancel out 'cycles of debt'. Nodes can also gain credit with other nodes by solving pointless problems. The innovation here is that when confronted with a puzzle, a node is able to delegate the work to its debtors. Proof of work is useful since, given the choice, a node would probably prefer to use its upstream bandwidth than burn up CPU time.
There are more details to this, like: the specifics of how to discover and execute a credit transfer along a long chain using only local interactions, how to incentive routing as well as data transfer and many other things.
If I had the time, I'd implement it.
The advantage of going with some sort of transpiler is that you can have two kinds of code within the same process whilst you make a gradual transition. I feel like, it could be made to work, but the boundary would have to be quite heavy-weight. Think less gradual typing and more FFI.
Edit: actually, in depends on which side is doing the calling. Going from checked to unchecked code is a minefield, but if it's unchecked code calling into checked code, it could work quite well as long as the arguments are immutable and don't have methods that can do IO.
Unfortunately, I don't think it's something that can be bolted on after the fact.