Heim > web3.0 > a16z: 8 Herausforderungen beim Design von Blockchain-Mechanismen

a16z: 8 Herausforderungen beim Design von Blockchain-Mechanismen

PHPz
Freigeben: 2024-06-11 10:12:28
Original
448 Leute haben es durchsucht

Titel von: „8 Gründe, WARUM das Design von Blockchain-Mechanismen schwierig ist“

a16z:区块链机制设计中的 8 个挑战

Autor: Tim RoughGarden, A16z Krypto-Forscher

Zusammenstellen: 0xxz, Gold Financial

Eingehende Untersuchung von In einem Feld lernen Sie zu erkennen, dass Probleme, die in der realen Welt auftreten, nur schlechte Verschleierungen für Probleme sind, die gut gelöst wurden. Wenn ich zum Beispiel Algorithmen-Grundlagen unterrichte, lernen die Schüler, wie sie Probleme identifizieren, die auf die Berechnung kürzester Wege oder die lineare Programmierung hinauslaufen.

Diese Art des Mustervergleichs ist auch beim Mechanismusdesign wirksam. Dabei handelt es sich um eine Art „inverse Spieltheorie“, die Anreize nutzt, um gewünschte Ergebnisse zu erzielen. Werkzeuge und Lehren aus dem Mechanismusdesign sind besonders nützlich in der Auktionstheorie, dem Marktdesign und der Theorie sozialer Entscheidungen.

Crypto und Web3 sind voller mechanischer Designprobleme. Man könnte meinen, dass viele Probleme gelöst werden können, indem man Material aus Lehrbüchern anwendet und alten Ideen eine neue Wendung gibt. Allerdings zwingen die einzigartigen Herausforderungen und Einschränkungen erlaubnisloser Blockchain-Protokolle oft dazu, die Grundprinzipien eines scheinbar gelösten Problems zu überdenken. Dies erschwert das Design von Mechanismen in web3. Aber es sind diese Herausforderungen, die das Design von Web3-Mechanismen so faszinierend machen.

In diesem Artikel werde ich einige der Herausforderungen untersuchen, denen sich das Design von Web3-Mechanismen gegenübersieht. Diese Herausforderungen mögen krypto-nativen Benutzern bekannt sein, aber ein tieferes Verständnis des Mechanismusdesigns sollte allen Entwicklern eine neue Perspektive darüber eröffnen, warum die Lösung dieser Probleme so schwierig ist. Wenn Sie als Mechanismusdesigner über neue Anwendungen nachdenken, interessieren Sie sich möglicherweise für die Herausforderungen, die eine erlaubnisfreie Umgebung mit sich bringt.

Aber zuerst müssen wir wissen: Was ist Mechanismusdesign?

Die Entstehung des Gebiets des Mechanismusdesigns lässt sich mindestens bis ins Jahr 1961 zurückverfolgen, als der Ökonom der Columbia University und spätere Nobelpreisträger William Vickrey offiziell die versiegelte Zweitpreis-Auktion Way vorschlug. Diese Auktionsmethode wurde bereits 1797 verwendet, als der Autor Johann Wolfgang von Goethe das Manuskript seines epischen Gedichts Hermann und Dorothea verkaufte. Sie wurde im 19. Jahrhundert von Briefmarkensammlern häufig verwendet, wurde jedoch erst 1961 von Vickrey offiziell vorgeschlagen. und wird heute oft als „Vickrey-Auktion“ bezeichnet. Beim Vickery-Auktionsmodell gewinnt der Höchstbietende, zahlt aber das zweithöchste Gebot. Diese Art von Auktion weckt bei den Bietern echte Vorliebe und liefert das Los zum höchsten Schätzpreis.

Die Vickrey-Auktion ist ein elegantes und effizientes Design, das auf die reale Welt angewendet wurde und sich an neue Situationen anpasst und aktualisiert, wobei die Praxis die Theorie beeinflusst und umgekehrt. Wie bei Vickery Auction ist die Geschichte des Mechanismusdesigns als formale Disziplin eine Geschichte miteinander verflochtener Theorie und Praxis, die sowohl tiefgreifend als auch schön ist.

Im Gegensatz zur Spieltheorie – die die Dimension strategischer Interaktion festlegt und die sinnvollsten Konsequenzen von Verhalten erforscht – beginnt das Gebiet des Mechanismusdesigns nicht mit dem Spiel, sondern mit den gewünschten Ergebnissen. Der Zweck des Mechanismusdesigns besteht darin, eine Form des Spiels zurückzuentwickeln, sodass ein gewünschtes Ergebnis (das möglicherweise durch Effizienz, Fairness oder bestimmte Verhaltensweisen gekennzeichnet ist) ausgeglichen wird. Im Fall von Vickery Auctions besteht das ultimative Ziel darin, die Teilnehmer dazu zu bewegen, den Höchstbetrag zu zahlen, den sie zu zahlen bereit sind, ohne sie zu bestrafen.

Es gibt viele Anwendungsmöglichkeiten für das Mechanismusdesign in Web3. Beispielsweise möchte ein Blockchain-Protokoll möglicherweise Ergebnisse erzielen, bei denen sich die Protokollteilnehmer mit Integrität verhalten (ohne vom erwarteten Verhalten abzuweichen). Alternativ möchte ein Protokoll möglicherweise genaue Informationen über Transaktionswerte erhalten, um Blockraum effizient den wertvollsten Transaktionen zuzuweisen.

Solche Probleme beim Mechanismusdesign sind immer eine Herausforderung, und die Herausforderungen sind in einer Blockchain-Umgebung noch einzigartiger.

1. Mangelndes Vertrauen

Wenn es keine vertrauenswürdige Partei gibt, die den Mechanismus ausführt, wird die Gestaltung des Blockchain-Feldes schwieriger.

Der springende Punkt bei der Verwendung eines erlaubnislosen Blockchain-Protokolls ist, dass Sie keiner einzelnen Entität oder Person vertrauen müssen, sondern nur der „durchschnittlichen“ Vertrauensannahme, dass genügend Knoten, auf denen das Protokoll ausgeführt wird, ehrlich sind.

Aber die Ironie vieler Blockchain-Architekturen besteht darin, dass jeder Stapel von Transaktionen, die zum Kettenverlauf hinzugefügt werden, um in der vom Protokoll verwalteten virtuellen Maschine ausgeführt zu werden, das Produkt einseitiger Entscheidungen eines einzelnen Knotens ist.

Sie wissen nicht, ob Sie diesem Knoten vertrauen können.

Aus diesem Grund sind Vickery-Auktionen im Blockchain-Bereich selten anzutreffen. Eine naive Implementierung von Vickery-Auktionen stößt schnell auf das Problem der Manipulation durch nicht vertrauenswürdige Blockproduzenten. Das Problem besteht darin, dass ein Blockproduzent ein gefälschtes „Shill Bid“-Gebot erstellen kann, das etwas niedriger ist als das Gebot des zukünftigen Gewinners, wodurch der Gewinner gezwungen wird, fast sein gesamtes Gebot zu zahlen (anstelle des echten zweithöchsten Gebots). .

Gefälschte Gebote von nicht vertrauenswürdigen Blockproduzenten führten effektiv dazu, dass Vickery Auctions auf den Erstpreisauktionsmodus zurückfiel, was einer der Gründe ist, warum Erstpreisauktionen in web3 so häufig vorkommen. (Der neueste Zweig der traditionellen Mechanismus-Design-Literatur zu „vertrauenswürdigen Mechanismen“ betrachtet auch das Auktionsdesign nicht vertrauenswürdiger Auktionatoren, jedoch aus einer anderen Perspektive.)

2. Manchmal gibt es Absprachen

Blockchain-Mechanismus Ein weiterer Grund für das Design Die Schwierigkeit besteht in der Möglichkeit einer Absprache zwischen Blockchain-Teilnehmern. So können Zweitpreisauktionen leicht mit Schadensersatzzahlungen verhandelt werden. Die Idee ist einfach: Da der erfolgreiche Bieter das zweithöchste Gebot zahlt, kann der Bieter den zweithöchsten Bieter bestechen, damit er ein viel niedrigeres Gebot abgibt.

Die wissenschaftliche Literatur zum Mechanismusdesign beschäftigt sich nicht allzu sehr mit diesem Thema. Ein Grund könnte darin liegen, dass Absprachen, insbesondere bei Entschädigungszahlungen, in der Praxis nur schwer zu erreichen sind. Nach einer Absprache kann der Gewinner die Zahlung des Bestechungsgeldes verweigern, so dass es schwierig ist, glaubwürdige Entschädigungszahlungen zu erhalten. (Wie das Sprichwort sagt: „Es gibt keine Gerechtigkeit unter Dieben.“)

Allerdings können potenzielle Betrüger im Kontext der Blockchain häufig intelligente Verträge nutzen, um verlässliche Zusagen zu machen, damit die Absprache wirklich funktioniert. Der zweite Grund ist das Fehlen eines Mechanismus zur Verhinderung von Absprachen bei Entschädigungszahlungen – des „Preisoffenlegungs“-Mechanismus, der nur Angebote und sonst nichts bereitstellt.

Schlimmer noch: Protokollbenutzer können nicht nur untereinander, sondern auch mit (nicht vertrauenswürdigen) Blockproduzenten zusammenarbeiten (das Äquivalent einer Absprache zwischen Bietern und Auktionatoren in realen Auktionen).

Der Widerstand gegen diese letzte Art von Absprache ist einer der Hauptgründe für die Verbrennung von Transaktionsgebühren im EIP-1559-Transaktionsgebührenmechanismus von Ethereum. Ohne diese Einnahmen zu „verbrennen“ (oder den Blockproduzenten auf andere Weise vorzuenthalten), können Blockproduzenten und Endnutzer durch Kompensationszahlungen kooperieren und sich jedem Reservierungspreis entziehen, den der Mechanismus durchzusetzen versucht.

3. Wir können uns nicht allein auf die Rechtsstaatlichkeit verlassen

Das Problem der Absprachen ist offensichtlich nicht neu. Es beschäftigt die Mechanik im wirklichen Leben schon seit Jahrhunderten, aber wenn man sich die Fachliteratur zum Mechanismusdesign anschaut, wird man überrascht sein, wie wenig darin behandelt wird. Diese Literatur befasst sich zwar direkt mit den Beweggründen einzelner Akteure, Mechanismen einseitig zu manipulieren, überlässt die Frage jedoch im Allgemeinen einem noch unerwarteten Konzept der „Rechtsstaatlichkeit“. Beispielsweise könnten die Teilnehmer des Mechanismus einen rechtsgültigen Vertrag unterzeichnen, der vorsieht, dass sie keine Absprachen treffen. Wenn eine Absprache festgestellt wird, wird dies auf rechtliche Wege verwiesen. Mechanismusdesigner können helfen, indem sie einen Mechanismus entwickeln, der es relativ einfach macht, Absprachen zu erkennen.

Ein Großteil der Literatur zum Mechanismusdesign birgt ein unausgesprochenes Geheimnis: das Vertrauen auf die Rechtsstaatlichkeit. Wir können zwar nicht sagen, dass es im Bereich erlaubnisloser Blockchain-Protokolle keine Rechtsstaatlichkeit gibt – wir sehen oft, dass Strafverfolgungsbehörden Straftaten auf erlaubnislosen Blockchains erfolgreich verfolgen –, der Grad der Rechtsstaatlichkeit ist jedoch weitaus seltener als bei traditionellen Mechanism-Design-Anwendungen. .

Wenn Sie sich außerhalb des Mechanismus nicht auf die Rechtsstaatlichkeit verlassen können, liegt es in der Verantwortung des Designers, das Problem innerhalb des Mechanismus zu beheben. Dieser Ansatz ist bei Entscheidungen zum Mechanismusdesign im Blockchain-Bereich weit verbreitet. Insbesondere im Ethereum-Protokoll gibt es zahlreiche Beispiele, von der Vernichtung von Grundgebühreneinnahmen durch EIP-1559 bis hin zur Kürzung von Validatoren wegen Fehlverhaltens in ihrem Konsensprotokoll.

4. Größerer Designraum

Der Designraum in web3 ist größer als das, was Mechanismusdesigner gewohnt sind. Daher müssen Designer jedes gegebene Problem überdenken. Beispielsweise beinhalten viele Mechanismen Zahlungen, die in traditionellen Mechanismendesignanwendungen in Fiat-Währungen wie US-Dollar erfolgen würden. Viele Blockchain-Protokolle haben ihre eigene native Währung und Mechanismen innerhalb des Protokolls sind in der Lage, diese Währungen zu manipulieren.

Stellen Sie sich vor, Sie hätten einen Artikel über das Design traditioneller Mechanismen geschrieben. Ein Teil Ihrer Mechanismusbeschreibung lautet: „Drucken Sie eine Reihe neuer Währungen und verteilen Sie sie an eine Gruppe von Teilnehmern. Wenn Sie über den Kontext der Blockchain hinausschauen, ist das lächerlich.“ Aber wenn man über Mechanismusdesign im Kontext eines Blockchain-Protokolls spricht, ist das durchaus möglich. Das Protokoll kontrolliert die Währung, sodass Teile der Protokollmechanik Token prägen oder Token verbrennen können.

Das bedeutet, dass einige Designs möglich werden, die ohne die Landeswährung unmöglich wären. Wie können Sie beispielsweise Bitcoin-Miner dazu anregen, das Protokoll wie beabsichtigt auszuführen? Anreize für diese Blockproduzenten durch inflationäre Belohnungen: Drucken neuer Münzen (Bitcoins). Ohne eine einheimische Währung wäre ein solches Design nicht möglich.

5. Die einheimische Währung kann andere Probleme mit sich bringen

Der vorherige Grund unterstreicht die Macht der einheimischen Währung. Mit der einheimischen Währung können Sie zwei Dinge tun: „Minting“ (die Art und Weise, wie das Bitcoin-Protokoll neue Bitcoins prägt, um Anreize für Miner zu schaffen) und „Token verbrennen“ (die Art und Weise, wie der EIP-1559-Transaktionsgebührenmechanismus von Ethereum die ETH verbrennt, um Absprachen zu verhindern). In einheimischen Währungen lauert eine Gefahr, die beim traditionellen Mechanismusdesign nicht besteht: Mikroökonomische Designentscheidungen können makroökonomische Konsequenzen haben.

Beim traditionellen Mechanismusdesign gibt es keinen Grund, sich über makroökonomische Kräfte Sorgen zu machen. Traditionelle Auktionen hatten keinen nennenswerten Einfluss auf die US-Geldmenge oder die Inflationsrate. Dies ist eine völlig neue Herausforderung in der Welt des Web3-Designs. Was könnte schiefgehen? Lassen Sie mich Ihnen zwei Beispiele nennen, eines über die Prägung von Bitcoin und das andere über die Verbrennung von ETH.

Aufgrund der Verwendung von Blockbelohnungen – Anreize für Miner durch das Drucken neuer Münzen – ist Bitcoin gezwungen, eine Inflation zu erleben. Daher muss es auch eine entsprechende Geldpolitik geben, die die Inflationsrate und deren zeitliche Entwicklung bestimmt. Satoshi Nakamoto legte außerdem eine feste Angebotsobergrenze von 21 Millionen Bitcoins fest. Da es eine feste Obergrenze für die Anzahl der Bitcoins gibt, muss die Inflationsrate gegen Null gehen.

Wenn die Inflationsrate wirklich Null ist, was sollte dann verwendet werden, um Bergleute zu motivieren, das Protokoll weiterhin zu betreiben und Sicherheit für Bitcoin zu bieten? Es wurde gehofft, dass die Transaktionsgebühren die fehlenden Blockbelohnungen ausgleichen würden, obwohl die Wahrscheinlichkeit, dass dies geschieht, eher gering ist. Es ist bekannt, dass das Bitcoin-Protokoll unter erheblichen Sicherheitsproblemen leiden wird, wenn die Transaktionsgebühren gegen Null gehen.

Die Informatiker Miles Carlston, Harry Kalodner, Matthew Weinberg und Arvind Narayanan von der Princeton University haben in einem Artikel auf einen weiteren Unterschied zwischen Transaktionsgebühren und Blockbelohnungen hingewiesen. Während die Blockbelohnung für jeden Block gleich ist (zumindest zwischen zwei aufeinanderfolgenden Blockbelohnungs-„Halbierungen“), können die Transaktionsgebühren um Größenordnungen variieren – was wiederum zu einer neuen spieltheoretischen Instabilität führt. In diesem Sinne hat die makroökonomische Entscheidung, eine Angebotsobergrenze festzulegen, negative mikroökonomische Folgen für das Protokoll und seine Teilnehmer.

Genau wie die Prägung von Blockprämien eine inflationäre Kraft für Bitcoin war, ist die Verbrennung von Transaktionsgebühren in EIP-1559 eine deflationäre Kraft für Ethereum. Im Ethereum-Protokoll (das inflationäre Validator-Belohnungen verwendet) gibt es ein Tauziehen zwischen diesen beiden Kräften, wobei oft die Deflation siegt. ETH ist nun eine Nettodeflationärwährung, eine makroökonomische Folge der mikroökonomisch motivierten Designentscheidungen im Transaktionsgebührenmechanismus des Protokolls.

Ist Deflation gut oder schlecht für das Ethereum-Protokoll? ETH-Inhaber lieben die Deflation, weil ihre Token unter sonst gleichen Bedingungen mit der Zeit wertvoller werden. (Tatsächlich könnte dieses Nebenprodukt letztendlich dazu geführt haben, dass sich die öffentliche Meinung für den Übergang zum Transaktionsgebührensystem von EIP-1559 aussprach.) Der Begriff Deflation schreckt jedoch traditionell ausgebildete Makroökonomen ab und erinnert an die wirtschaftliche Stagflation in Japan in den 1990er Jahren.

Wer hat Recht? Persönlich glaube ich nicht, dass staatliche Fiat-Währungen die richtige Analogie zu Kryptowährungen wie der ETH sind. Was ist also die richtige Analogie? Dies bleibt eine offene Frage, die einer weiteren Untersuchung durch Blockchain-Forscher bedarf: Warum kann eine deflationäre Währung als Kryptowährung fungieren, die ein Blockchain-Protokoll unterstützt, aber nicht als Fiat-Währung, die einen souveränen Staat unterstützt?

6. Ignorieren Sie nicht den zugrunde liegenden Stack

In der Informatik streben wir unter anderem nach Modularität und sauberer Abstraktion, die uns die Fähigkeit gibt, bestimmten Teilen des Systems zu vertrauen. Wenn Sie einen Teil eines Systems entwerfen und analysieren, müssen Sie möglicherweise die Funktionalität der Ausgabe anderer Teile des Systems kennen. Aber im Idealfall müssen Sie nicht wissen, wie diese Funktionalität unter der Haube implementiert wird.

Bei Blockchain-Protokollen haben wir diesen Idealzustand noch nicht erreicht. Während Entwickler und Mechanismusdesigner sich gerne auf die Anwendungsschicht konzentrieren, können sie die Funktionsweise und Details der Infrastrukturschicht nicht außer Acht lassen.

Wenn Sie beispielsweise einen automatisierten Market Maker entwerfen, müssen Sie die Möglichkeit in Betracht ziehen, dass nicht vertrauenswürdige Blockproduzenten für die Transaktionsbestellung verantwortlich sind. Wenn Sie alternativ darüber nachdenken, einen Transaktionsgebührenmechanismus für ein (L2-)Rollup zu entwerfen, müssen Sie nicht nur für den L2-Ressourcenverbrauch zahlen, sondern auch für alle Kosten, die durch das zugrunde liegende L1-Protokoll entstehen (z. B. das Speichern von Anrufdaten).

In beiden Beispielen erfordert ein effektives Mechanismusdesign auf einer Ebene detaillierte Kenntnisse über die anderen Ebenen. Wenn die Blockchain-Technologie ausgereifter wird, werden wir möglicherweise eine klare Trennung der verschiedenen Schichten erreichen. Aber so weit sind wir sicher noch nicht.

7. Erforderlich für die Arbeit in einer rechenbeschränkten Umgebung

Der durch das Blockchain-Protokoll implementierte „Computer im Himmel“ ist eine rechenbegrenzte Umgebung. Das traditionelle Mechanismusdesign konzentriert sich nur auf wirtschaftliche Anreize und ignoriert rechnerische Probleme (beispielsweise ist der berühmte Vickery-Clarke-Groves-Mechanismus für hochkomplexe Allokationsprobleme undurchführbar).

Als Nisan und Ronen 1999 das Design algorithmischer Mechanismen vorschlugen, wiesen sie darauf hin, dass wir wirklich eine Art rechnerische Nachvollziehbarkeit brauchten, um dem Mechanismus in der realen Welt Bedeutung zu verleihen. Daher empfehlen sie, die Aufmerksamkeit auf Berechnungs- und Kommunikationsmechanismen zu beschränken, die bestimmte Größen als polynomische (statt exponentielle) Funktionserweiterungen als Problemparameter verwenden.

Da die Rechenlast der virtuellen Maschine des Blockchain-Protokolls sehr gering ist, muss der On-Chain-Mechanismus sehr leichtgewichtig sein – Polynomzeit und Kommunikation sind notwendig, aber nicht ausreichend. Knappheit ist beispielsweise der Hauptgrund dafür, dass automatisierte Market Maker Ethereum DeFi vollständig dominieren, und nicht traditionellere Lösungen wie Limit-Orderbücher.

8. Noch im Anfangsstadium

Wenn Leute sagen, dass sich web3 im Anfangsstadium befindet, beziehen sie sich normalerweise entweder auf Investitionsmöglichkeiten oder auf die Einführung. Aber aus wissenschaftlicher Sicht sind wir noch früher dran. Es wird nur noch schwieriger – auch wenn die Chancen riesig sind.

Die Vorteile der Arbeit in einem etablierten Forschungsgebiet sind für alle selbstverständlich. Es gibt allgemein anerkannte Modelle und Definitionen. In den wichtigsten Fragen konnte Konsens erzielt werden. Die Schlüsselkoordination entwickelte sich auch rund um die Fortschrittsmessung. Es gibt einen gemeinsamen Wortschatz und eine umfangreiche öffentliche Wissensbasis. Es gibt auch Möglichkeiten zur Beschleunigung, einschließlich streng geprüfter Lehrbücher, Online-Kurse und anderer Ressourcen.

Gleichzeitig kennen wir in vielen Aspekten des Blockchain-Bereichs noch nicht die „richtigen“ Modelle und Definitionen, um klar zu denken und bei wichtigen Themen Fortschritte zu erzielen. Was sind beispielsweise die wichtigsten Konzepte von Kompatibilitätsanreizen im Kontext von Blockchain-Protokollen? Was sind die Schichten des Web3-Stacks? Was sind die Komponenten des Maximum Extractable Value (MEV)? Das sind alles unbeantwortete Fragen.

Für diejenigen, die sich für die Blockchain-Wissenschaft interessieren, ist die Unreife des Fachgebiets tatsächlich eine Herausforderung. Aber wenn man sich frühzeitig – und zwar jetzt – engagiert, ergeben sich auch einzigartige Chancen.

Mechanismusdesign war schon immer ein nützliches Werkzeug auf der Ebene von Internetanwendungen – etwa bei Echtzeit-Werbeauktionen oder dem zweiseitigen Marktdesign, das heute in den meisten Online-Verbraucheranwendungen vorherrscht, vom E-Commerce bis zum Gruppenkauf .

Aber in Web3 beeinflusst das Mechanismusdesign auch Designentscheidungen für die Infrastruktur selbst.

Denken Sie zurück an die 1970er und 1980er Jahre, als sich Internet-Routing-Protokolle noch in der Diskussions- und Entwurfsphase befanden. Soweit ich weiß, sitzt kein Profi im Bereich Anreiz- und Mechanikdesign mit am Tisch. Im Nachhinein erkennen wir nun, dass eine solche Person nützliche Informationen für den Entwurf hätte liefern können. Mittlerweile waren bei web3 mit der Veröffentlichung des ursprünglichen Bitcoin-Whitepapers Anreize von Anfang an Teil der Diskussion.

Die Verwirrung rund um das „richtige“ Modell, die richtige Definition und die „richtigen“ Erfolgsmetriken für web3 zeigt uns tatsächlich, dass wir uns in einem goldenen Zeitalter befinden. Zukünftige Generationen von Studenten und Wissenschaftlern werden uns beneiden, dass wir zur richtigen Zeit am richtigen Ort waren und die Möglichkeit hatten, die Entwicklung dieser Technologie mitzugestalten. Auch wenn es in diesem Bereich vielleicht nicht viele Lehrbücher gibt, wird es sie eines Tages geben, und was in diesen Büchern beschrieben wird, ist das, was wir jetzt tun.

Das obige ist der detaillierte Inhalt vona16z: 8 Herausforderungen beim Design von Blockchain-Mechanismen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Quelle:chaincatcher.com
Erklärung dieser Website
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Beliebte Tutorials
Mehr>
Neueste Downloads
Mehr>
Web-Effekte
Quellcode der Website
Website-Materialien
Frontend-Vorlage