It has an elevated reservebalance level and a blocknotify script specialised to testnet.
“What blocknotify script?” asks a hypothetical discourse device. Well, the client can be configured to execute a specified program whenever the client receives a new block.
In my
slimcoin_testnet.conf it is configured as a shell script:
blocknotify=/opt/slm/scripts/slm-testnet-blocknotify.sh %s
when executed, the
%s gets replaced by the actual block hash, bound in the shell environment to
$@.
The shell script:
#!/bin/sh
BLOCKHASH="$@" /usr/bin/python3.5 /opt/slm/scripts/slm-testnet-blocknotify.py > /tmp/blocknotify.log 2>&1
echo "${@}" >> /tmp/blocknotify.log
which, in turn, runs a Python script that picks up the block hash from the environment, performs a series of RPC calls on the client, starting with
getblock <BLOCKHASH>, converting the returned JSON statements into RDF statements and working its way through the pointers finally to create an complete RDF graph representation of the block, its transactions, their values and the addresses involved. It records around three dozen facts about each block.
(~950000 blocks * 36 triples = 34,200,000 triples, so an RDF graph of mainnet will a) take time to generate and b) have to be maintained in separate chunks. Fortunately SPARQL can run “federated” queries, i.e. treat the separate chunks as one for querying porpoises.)
The RDF is then posted to an instance of the Apache Jena
Fuseki SPARQL server running on the (same) machine which then offers SPARQL querying of a contemporaneous RDF graph of the blockchain.
The following image shows a SPARQL query that lists all distinct OP_RETURN tx messages on the testnet blockchain:
(The SPARQL endpoint shown in the image is active and accessible)
That's all she wrote, literally. If we want to provide more information about a particular inscription, such as a description of the nature of the content of the torrent identified by the inscribed torrent hash, then for us it has to be off-chain.
Off-chain data storage is often implemented by creating additional data tables in the
-datadir. Unfortunately, this approach also adds significantly to the maintenance load and this directly translates into a significant increase in the cost of ownership for the already woefully under-supported user. Let’s be realistic, people aren't exactly queuing up to shoulder the load of curating the content that they create in the course of their netsocializing, they much prefer it to be someone else's problem even at the price of a significant concession of privacy.
The real show-stopper is that the locally-stored data isn't broadcast across the peer-to-peer network, it remains locally siloed and thus useful to neither man nor beast.
A more plausible approach would be to engineer a reliable external social consensus using an RDF graph representation of the blockchain for provable veracity. The RDF representation is both public and accessible so it's trivial to establish whether or not it's a correct mapping from the acyclic directed blockchain graph to the acyclic directed RDF graph.
Given that the RDF graph is a one-to-one
symbolic correspondence to the blockchain, referring to
:C0000000733567067927d0778bdee1ad3034ecc60e49cfc3ae05dbc3a1eddbb60 will get you the recorded metadata for that block:
:C0000000733567067927d0778bdee1ad3034ecc60e49cfc3ae05dbc3a1eddbb60 a :Block ;
:difficulty 0.06464541 ;
:flags "proof-of-work"^^xsd:string ;
:height 759 ;
:mint 6.19 ;
:previousblockhash :C8fe77bb34c5aec9206a3c73beccaf1fc53e6d4afe297c3782f57c09e4eb9c627 ;
:size 355 ;
:time 1492346152 .The absence of a statement about the
nextblock defines this as the last block in the chain at the time recorded.
So, given that the query:
SELECT ?subject
WHERE {
?subject rdf:type <http://purl.org/net/bel-epa/ccy#TransactionOutput> .
?subject <http://purl.org/net/bel-epa/ccy#inscription> "magnet:?xt=urn:btih:e940a7a57294e4c98f62514b32611e38181b6cae"
}yields a reference to the TxO
<http://purl.org/net/bel-epa/ccy#C1887d7380f770c99c0f9d08c38b7f01d71913b2ce791d1771ddfcfddda69f49d-O-2>I can make further statements, using the retrieved TxO reference as an identifier and using expressions drawn from familiar vocabularies (in this instance, for clarity I'm using just the
Dublin Core metadata elements):
:gjh-00000001 a :Inscription ;
:inscription "magnet:?xt=urn:btih:e940a7a57294e4c98f62514b32611e38181b6cae"^^xsd.string ;
dc:title "Arch Linux 2013.01.04 (www.archlinux.org)"^^xsd.string ;
dc:date 2013-01-04T22:09:20Z ;
dc:identifier http://purl.org/net/bel-epa/ccy#C1887d7380f770c99c0f9d08c38b7f01d71913b2ce791d1771ddfcfddda69f49d-O-2 ;
dc.source: "magnet:?xt=urn:btih:c8cde7428b44142b04d88b91785ecf0f20d16903&dn=archlinux-2013.02.01-x86_64.iso&tr=udp://tracker.archlinux.org:6969&tr=http://tracker.archlinux.org:6969/announce" ;
dc:description "kernel_version 3.6.11"^^xsd.string .I can add that to my local graph, dump it on pastebin or, one day in the dim and distant future, I could even publish it to a group-maintained community-serving RDF graph running on several DO/AWS instances so that other users can choose to add to their whitelisted resources.
Cheers
Graham
