I don't see any way in making this kind of thing really tamper-proof for anyone wanting to manipulate the blacklisting of files (but as in most cases in our world we are satisfied with good approximation instead of a perfect scheme). As der_schreckliche_sven stated you can only trust your own servent, this is true. But if you are willing to say that you can also (at least in some ways) trust 80% of the other servents, that would clearly be enough to implement a good rating scheme.

What I consider being possible would be to broadcast the file checksum and rating whenever a user rates a file that he has downloaded (just like search requests are broadcasted with a given TTL). All servents that receive that kind of rating messages could update their internal rating database that map file checksums to the kind and number of ratings received so far for that file. As the database is internal to a servent, no centralized server must be contacted when a rating should be shown to the user in the GUI, because all rating data is present locally. And with this approach no centralization at all is required (but of course some extra bandwidth is required for broadcasting the rating messages on the Gnet).

Tampered-with files can probably be detected easily, because in those cases the ratings will be (highly) contradictive. For example, the RIAA/MPAA would try to rate all "stolen" movie files as being e.g. "broken content" (possibly with quite a large number of fake servents that initiate broadcasting those rating messages), whereas everyone else that has downloaded the file would rate it as being good (this would be vice versa for fake files that the RIAA/MPAA contributes to the network; they would declare them as good whereas the users would declare them as bad). As the RIAA/MPAA fake servents would be in a minority compared to the number of "real" P2P users it would IMO be enough to provide the user in the GUI a final rating for a file that is the majority of all the different ratings received (e.g. when a servent has received for a given file 9600 ratings of "good quality", 120 ratings of "virus" and 70 ratings of "broken content", the majority would be "good quality" and the file could be handled as being so). And if a user is really curious (e.g. for large files) the GUI could display the details of the received ratings to the user.