{"id":53183,"date":"2019-11-25T00:00:00","date_gmt":"2019-11-24T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/ot-blokchejna-k-dag-izbavlyaemsya-ot-posrednikov"},"modified":"2026-02-15T19:54:48","modified_gmt":"2026-02-15T17:54:48","slug":"ot-blokchejna-k-dag-izbavlyaemsya-ot-posrednikov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ot-blokchejna-k-dag-izbavlyaemsya-ot-posrednikov","title":{"rendered":"Von Blockchain zu DAG: Wir befreien uns von Vermittlern","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

In diesem Artikel werde ich Ihnen DAG (Directed Acyclic Graph, gerichteter azyklischer Graph) und seine Anwendungen in verteilten Ledgern vorstellen und ihn mit Blockchain vergleichen.<\/p>\n

\"Von
\n
\nDAG ist im Kryptow\u00e4hrungsbereich keine Neuheit. M\u00f6glicherweise haben Sie bereits von ihm als L\u00f6sung f\u00fcr die Skalierbarkeitsprobleme von Blockchains geh\u00f6rt. Doch heute werden wir nicht \u00fcber Skalierbarkeit sprechen, sondern dar\u00fcber, was Kryptow\u00e4hrungen von allem anderen unterscheidet: Dezentralisierung, das Fehlen von Intermedi\u00e4ren und Zensurresistenz.
\n<\/a><\/noindex>
\n\"Von
\n
\nIch werde Ihnen auch zeigen, dass DAG tats\u00e4chlich zensurresistenter ist und keine Intermedi\u00e4re ben\u00f6tigt, um auf das Ledger zuzugreifen.<\/p>\n

\"Von
\n
\nIn den uns bekannten Blockchains haben die Nutzer keinen direkten Zugriff auf das Ledger selbst. Wenn Sie eine Transaktion in das Ledger einf\u00fcgen m\u00f6chten, m\u00fcssen Sie den Blockproduzenten (auch als Miner bekannt) darum \u201ebitten\u201c, dies f\u00fcr Sie zu tun. Die Miner entscheiden, welche Transaktion in den n\u00e4chsten Block aufgenommen wird und welche nicht. Nur die Miner haben exklusiven Zugang zu den Bl\u00f6cken und das Recht zu entscheiden, wessen Transaktion akzeptiert wird.<\/p>\n

Miner sind die Intermedi\u00e4re, die zwischen Ihnen und dem verteilten Ledger stehen.<\/p>\n

\"Von
\n
\nIn der Praxis kontrolliert in der Regel eine kleine Anzahl von Mining-Pools kollektiv mehr als die H\u00e4lfte der Rechenleistung des Netzwerks. Bei Bitcoin sind das vier Pools, bei Ethereum zwei. Im Falle einer Abmachung k\u00f6nnen sie beliebige Transaktionen blockieren, die sie m\u00f6chten.<\/p>\n

\"Von
\n
\nIn den letzten Jahren wurden viele Variationen von Blockchains vorgeschlagen, die sich in den Prinzipien zur Auswahl der Blockproduzenten unterscheiden. Die Blockproduzenten selbst verschwinden jedoch nicht; sie stehen weiterhin \"an der Schranke\": Jede Transaktion muss durch den Blockproduzenten gehen, und wenn dieser sie nicht akzeptiert, existiert die Transaktion faktisch nicht.<\/p>\n

\"Von
\n
\nDas ist ein unvermeidliches Problem im Zusammenhang mit Blockchain-Technologie. Wenn wir es l\u00f6sen wollen, m\u00fcssen wir das Design radikal \u00e4ndern und vollst\u00e4ndig auf Bl\u00f6cke und Blockproduzenten verzichten. Statt eine Kette von Bl\u00f6cken aufzubauen, w\u00fcrden wir die Transaktionen selbst verkn\u00fcpfen und in jede Transaktion Hashes mehrerer vorhergehender Transaktionen einf\u00fcgen. Dadurch erhalten wir eine Struktur, die in der Mathematik als gerichteter azyklischer Graph \u2013 DAG bekannt ist.<\/p>\n

Jetzt hat jeder direkten Zugang zum Register, ohne Zwischenh\u00e4ndler. Wenn Sie eine Transaktion zum Register hinzuf\u00fcgen m\u00f6chten, f\u00fcgen Sie sie einfach hinzu. W\u00e4hlen Sie mehrere \u00fcbergeordnete Transaktionen aus, f\u00fcgen Sie Ihre Daten hinzu, signieren Sie und senden Sie Ihre Transaktion \u00fcber das Netzwerk. Fertig. Es gibt niemanden, der Ihnen dabei im Weg stehen kann, sodass Ihre Transaktion bereits im Register ist.<\/p>\n

Dies ist die dezentralisierteste und zensurunempfindlichste Methode, um Transaktionen ohne Zwischenh\u00e4ndler in das Register einzuf\u00fcgen. Denn jeder, der m\u00f6chte, f\u00fcgt einfach seine Transaktionen in das Register ein, ohne um Erlaubnis zu fragen.<\/p>\n

\"Von
\n
\nDAG kann als die dritte Phase der Evolution von Registern angesehen werden. Zun\u00e4chst gab es zentralisierte Register, bei denen eine Partei den Zugang kontrollierte. Dann kamen die Blockchains, in denen es bereits mehrere Kontrolleure gab, die Transaktionen im Register aufzeichneten. Schlie\u00dflich gibt es im DAG \u00fcberhaupt keine Kontrolleure, die Benutzer f\u00fcgen ihre Transaktionen direkt hinzu.<\/p>\n

\"Von
\n
\nJetzt, wo wir so viel Freiheit haben, darf dies nicht zu Chaos f\u00fchren. Wir m\u00fcssen uns \u00fcber den Status des Registers einig sein. Und diese Einigung oder Konsens bedeutet normalerweise \u00dcbereinstimmung in zwei Punkten:<\/p>\n

    \n
  1. Was ist passiert?\n<\/li>\n
  2. In welcher Reihenfolge ist das geschehen?\n<\/li>\n<\/ol>\n

    \nDie erste Frage k\u00f6nnen wir leicht beantworten: Sobald eine korrekt ausgef\u00fchrte Transaktion dem Register hinzugef\u00fcgt wurde, hat sie stattgefunden. Und damit basta. Die Information dar\u00fcber mag verschiedene Teilnehmer zu unterschiedlichen Zeiten erreichen, aber letztendlich werden alle Knoten diese Transaktion erhalten und erfahren, dass sie stattgefunden hat.<\/p>\n

    W\u00e4re das ein Blockchain, w\u00fcrden die Miner entscheiden, was geschieht. Alles, was der Miner beschlie\u00dft, in den Block aufzunehmen \u2013 geschieht. Alles, was er nicht in den Block aufnimmt \u2013 geschieht nicht.<\/p>\n

    In Blockchains l\u00f6sen die Miner auch das zweite Konsensproblem: die Reihenfolge. Ihnen ist es gestattet, die Transaktionen innerhalb des Blocks nach Belieben anzuordnen.<\/p>\n

    Wie bestimmt man die Reihenfolge der Transaktionen im DAG?<\/p>\n

    \"Von
    \n
    \nNur weil unser Graph gerichtet ist, haben wir bereits eine gewisse Ordnung. Jede Transaktion verweist auf eine oder mehrere vorhergehende, \u00fcbergeordnete Transaktionen. Diese \u00fcbergeordneten Transaktionen beziehen sich wiederum auf ihre Vorg\u00e4nger, und so weiter. Die \u00fcbergeordneten Transaktionen m\u00fcssen offensichtlich vor den untergeordneten Transaktionen entstanden sein. Wenn eine der Transaktionen \u00fcber die Links \"Eltern-Kind\" erreicht werden kann, wissen wir genau, in welcher Reihenfolge die Transaktionen in dieser Kette liegen.<\/p>\n

    \"Von
    \n
    \nDie Reihenfolge zwischen Transaktionen l\u00e4sst sich jedoch nicht immer nur aus der Form des Graphen ableiten. Zum Beispiel, wenn zwei Transaktionen auf parallelen \u00c4sten des Graphen liegen.<\/p>\n

    \"Von
    \n
    \nUm Mehrdeutigkeit in solchen F\u00e4llen zu kl\u00e4ren, verlassen wir uns auf sogenannte Reihenfolgeberater. Diese nennen wir auch \"Zeugen\". Das sind normale Nutzer, deren Aufgabe es ist, Transaktionen in die Netzwerkkette einzuf\u00fcgen, w\u00e4hrend sie die Reihenfolge einhalten, d.h. so, dass jede ihrer vorhergehenden Transaktionen \u00fcber die Links \"Eltern-Kind\" erreicht werden kann. Reihenfolgeberater \u2013     vertrauensw\u00fcrdige Benutzer<\/a>, und das gesamte Netzwerk verl\u00e4sst sich darauf, dass sie diese Regel nicht verletzen. Um sicherzustellen, dass rational<\/b> Wir m\u00fcssen darauf vertrauen, dass jeder Order-Provider eine bekannte (nicht-anonyme) Person oder Organisation ist und etwas hat, das er verlieren kann, wenn er die Regeln verletzt, wie zum Beispiel seinen Ruf oder ein vertrauensbasiertes Gesch\u00e4ft.<\/p>\n

    \"Von
    \n
    \nDie Order-Provider werden von den Nutzern ausgew\u00e4hlt, und jeder Nutzer f\u00fcgt bei jeder Transaktion, die er ins Netzwerk sendet, eine Liste seiner vertrauensw\u00fcrdigen Provider hinzu. Diese Liste besteht aus 12 Providern, was eine recht kleine Anzahl ist, um die Identit\u00e4ten und den Ruf jedes einzelnen zu \u00fcberpr\u00fcfen, und ausreichend, damit das Netzwerk weiterhin funktioniert, auch wenn es unvermeidliche Probleme mit einer Minderheit der Order-Provider gibt.<\/p>\n

    Diese Liste der Provider variiert von Nutzer zu Nutzer, aber die Listen benachbarter Transaktionen d\u00fcrfen sich maximal um einen Provider unterscheiden.<\/p>\n

    \"Von
    \n
    \nJetzt, da wir die Order-Provider haben, k\u00f6nnen wir deren Transaktionen im DAG hervorheben und alle anderen Transaktionen um die von ihnen geschaffene Ordnung anordnen. Es ist m\u00f6glich, einen solchen Algorithmus zu erstellen (siehe     Obyte White Paper<\/a><\/noindex> f\u00fcr technische Details).<\/p>\n

    Die Ordnung im gesamten Netzwerk kann nicht sofort bestimmt werden; wir ben\u00f6tigen Zeit, bis die Konsensprovider eine ausreichende Anzahl ihrer Transaktionen gesendet haben, um die endg\u00fcltige Reihenfolge der vergangenen Transaktionen zu best\u00e4tigen.<\/p>\n

    Und da die Reihenfolge nur durch die Positionen der Transaktionen der Provider im DAG bestimmt wird, werden alle Knoten im Netzwerk fr\u00fcher oder sp\u00e4ter alle Transaktionen erhalten und zu denselben Schlussfolgerungen hinsichtlich der Reihenfolge der Transaktionen kommen.<\/p>\n

    \"Von
    \n
    \nSo haben wir einen Konsens dar\u00fcber, was geschehen ist: jede Transaktion, die in den DAG gelangt ist, ist geschehen. Wir haben auch einen Konsens \u00fcber die Reihenfolge der Ereignisse: Diese ist entweder aufgrund der Zusammenh\u00e4nge zwischen den Transaktionen ersichtlich oder ergibt sich aus der Reihenfolge der von den Konsensprovidern gesendeten Transaktionen. Das bedeutet, wir haben einen Konsens.<\/p>\n

    \"Von
    \n
    \nDiese Konsensvariante haben wir in Obyte. Obwohl der Zugang zum Obyte-Register vollst\u00e4ndig dezentralisiert ist, bleibt der Konsens \u00fcber die Reihenfolge der Transaktionen zentralisiert, da 10 von 12 Anbietern vom Sch\u00f6pfer (Anton Churjumow) kontrolliert werden, und nur zwei von ihnen sind unabh\u00e4ngig. Wir suchen Kandidaten, die einer der unabh\u00e4ngigen Anbieter von Transaktionen werden m\u00f6chten, um uns zu helfen, die Ordnung im Register zu dezentralisieren.<\/p>\n

    K\u00fcrzlich trat ein dritter unabh\u00e4ngiger Kandidat auf, der daran interessiert ist, einen Anbieter-Knoten zu etablieren und zu unterst\u00fctzen \u2013 die Universit\u00e4t Nikosia.<\/p>\n

    \"Von
    \n
    \nWie kontrollieren wir jetzt doppelte Ausgaben (double-spends)?<\/p>\n

    Nach den Regeln gewinnt die Transaktion, die zuerst in der endg\u00fcltigen Reihenfolge aller Transaktionen auftaucht, wenn zwei Transaktionen entdeckt werden, die dieselbe M\u00fcnze ausgeben. Die zweite wird durch den Konsensalgorithmus ung\u00fcltig gemacht.<\/p>\n

    \"Von
    \nWenn es m\u00f6glich ist, die Reihenfolge zwischen zwei Transaktionen, die eine M\u00fcnze ausgeben (nach den Eltern-Kind-Beziehungen), festzulegen, lehnen alle Knoten sofort einen solchen Versuch der doppelten Ausgaben ab.<\/p>\n

    \"Von
    \n
    \nWenn die Reihenfolge jedoch nicht aus den zwischen zwei solchen Transaktionen vorhandenen Elternbeziehungen erkennbar ist, werden beide in das Register aufgenommen, und wir m\u00fcssen auf den Konsens und die Reihenfolge zwischen ihnen durch die Order-Anbieter warten. Dann wird die fr\u00fchere Transaktion bevorzugt, w\u00e4hrend die zweite ung\u00fcltig wird.<\/p>\n

    \"Von
    \n
    \nObwohl die zweite Transaktion ung\u00fcltig wird, bleibt sie dennoch im Register, da sie bereits nachfolgende Transaktionen hat, die sich auf sie beziehen und nichts verletzen oder wissen, dass diese Transaktion k\u00fcnftig ung\u00fcltig wird. Andernfalls m\u00fcssten wir die Elternbeziehungen zu den g\u00fcltigen nachfolgenden Transaktionen entfernen, was das Hauptprinzip des Netzwerks verletzen w\u00fcrde \u2013 jede g\u00fcltige Transaktion wird in das Register aufgenommen.<\/p>\n

    \"Von
    \n
    \nDies ist eine sehr wichtige Regel, die es dem gesamten System erm\u00f6glicht, gegen Zensurversuche widerstandsf\u00e4hig zu sein.\u00a0<\/p>\n

    Stellen Sie sich vor, alle Order-Anbieter kommen \u00fcberein, eine bestimmte Transaktion zu \"zensieren\". Sie k\u00f6nnen sie ignorieren und sie niemals als \u201eElternteil\u201c f\u00fcr ihre Transaktionen ausw\u00e4hlen, aber das ist nicht genug \u2013 diese Transaktion kann immer noch indirekt als Elternteil einer anderen Transaktion erscheinen, die von einem beliebigen Benutzer des Netzwerks ausgegeben wurde, der nicht an der Verschw\u00f6rung beteiligt ist. Im Laufe der Zeit wird diese Transaktion immer mehr Kinder, Enkel und Urenkel von normalen Benutzern erhalten und sich wie eine Lawine ausbreiten, sodass alle beteiligten Orderanbieter auch diese Transaktionen ignorieren m\u00fcssen. Letztendlich werden sie die gesamte Netzwerkzensur anwenden m\u00fcssen, was einem Sabotageakt gleichkommt.<\/p>\n

    \"Von
    \n
    \nSo bleibt DAG zensurresistent, selbst wenn es eine Verschw\u00f6rung von Orderanbietern gibt, und \u00fcbertrifft damit die Zensurresistenz von Blockchain, bei der wir nichts tun k\u00f6nnen, wenn Miner beschlie\u00dfen, eine der Transaktionen nicht einzubeziehen. Das ergibt sich aus der Hauptmerkmale von DAG: Die Teilnahme am Ledger ist v\u00f6llig unabh\u00e4ngig und ohne Zwischenh\u00e4ndler, und Transaktionen sind unwiderruflich.
    \n
    Quelle:     habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u0432\u0430\u043c \u043e DAG (Directed Acyclic Graph, \u043d\u0430\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u043d\u044b\u0439 \u0430\u0446\u0438\u043a\u043b\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u0433\u0440\u0430\u0444) \u0438 \u0435\u0433\u043e \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u0438 \u0432 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u044b\u0445 \u0440\u0435\u0435\u0441\u0442\u0440\u0430\u0445, \u0438 \u043c\u044b \u0441\u0440\u0430\u0432\u043d\u0438\u043c \u0435\u0433\u043e \u0441 \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u043e\u043c. DAG \u043d\u0435 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0447\u0435\u043c-\u0442\u043e \u043d\u043e\u0432\u044b\u043c \u0432 \u043c\u0438\u0440\u0435 \u043a\u0440\u0438\u043f\u0442\u043e\u0432\u0430\u043b\u044e\u0442. \u0412\u043e\u0437\u043c\u043e\u0436\u043d\u043e \u0432\u044b \u0441\u043b\u044b\u0448\u0430\u043b\u0438 \u043e \u043d\u0451\u043c \u043a\u0430\u043a \u043e \u0440\u0435\u0448\u0435\u043d\u0438\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u0443\u0435\u043c\u043e\u0441\u0442\u0438 \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u043e\u0432. \u041d\u043e \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u043c\u044b \u0431\u0443\u0434\u0435\u043c \u0433\u043e\u0432\u043e\u0440\u0438\u0442\u044c \u043d\u0435 \u043e \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u0443\u0435\u043c\u043e\u0441\u0442\u0438, \u0430 \u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-53183","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Von der Blockchain zu DAG: Schluss mit Intermedi\u00e4ren | ProHoster","description":"In diesem Artikel werde ich Ihnen etwas \u00fcber DAG (Directed Acyclic Graph, gerichteter azyklischer Graph) und dessen Anwendung in verteilten Registern erz\u00e4hlen und wir werden es mit der Blockchain vergleichen. DAG ist kein neues Konzept in der Welt der Kryptow\u00e4hrungen. M\u00f6glicherweise haben Sie bereits von ihm als einer L\u00f6sung f\u00fcr die Skalierbarkeitsprobleme von Blockchains geh\u00f6rt. Heute werden wir jedoch nicht \u00fcber Skalierbarkeit sprechen, sondern \u00fcber...","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ot-blokchejna-k-dag-izbavlyaemsya-ot-posrednikov","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e\u0442 \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0430 \u043a DAG: \u0438\u0437\u0431\u0430\u0432\u043b\u044f\u0435\u043c\u0441\u044f \u043e\u0442 \u043f\u043e\u0441\u0440\u0435\u0434\u043d\u0438\u043a\u043e\u0432 | ProHoster","og:description":"\u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u0432\u0430\u043c \u043e DAG (Directed Acyclic Graph, \u043d\u0430\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u043d\u044b\u0439 \u0430\u0446\u0438\u043a\u043b\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u0433\u0440\u0430\u0444) \u0438 \u0435\u0433\u043e \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u0438 \u0432 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u044b\u0445 \u0440\u0435\u0435\u0441\u0442\u0440\u0430\u0445, \u0438 \u043c\u044b \u0441\u0440\u0430\u0432\u043d\u0438\u043c \u0435\u0433\u043e \u0441 \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u043e\u043c. DAG \u043d\u0435 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0447\u0435\u043c-\u0442\u043e \u043d\u043e\u0432\u044b\u043c \u0432 \u043c\u0438\u0440\u0435 \u043a\u0440\u0438\u043f\u0442\u043e\u0432\u0430\u043b\u044e\u0442. \u0412\u043e\u0437\u043c\u043e\u0436\u043d\u043e \u0432\u044b \u0441\u043b\u044b\u0448\u0430\u043b\u0438 \u043e \u043d\u0451\u043c \u043a\u0430\u043a \u043e \u0440\u0435\u0448\u0435\u043d\u0438\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u0443\u0435\u043c\u043e\u0441\u0442\u0438 \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u043e\u0432. \u041d\u043e \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u043c\u044b \u0431\u0443\u0434\u0435\u043c \u0433\u043e\u0432\u043e\u0440\u0438\u0442\u044c \u043d\u0435 \u043e \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u0443\u0435\u043c\u043e\u0441\u0442\u0438, \u0430 \u043e","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ot-blokchejna-k-dag-izbavlyaemsya-ot-posrednikov","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-11-24T21:00:00+00:00","article:modified_time":"2026-02-15T17:54:48+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"53183","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-15 17:55:40","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:29:27","updated":"2026-02-15 17:55:40"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/53183","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=53183"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/53183\/revisions"}],"predecessor-version":[{"id":161174,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/53183\/revisions\/161174"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=53183"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=53183"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=53183"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}